Thinking about scrapping my idea of writing a custom membership and roles provider. Opinions?

Question

I've got a web app I'm building in ASP.NET that has the following security requirements:

1. Must be able to integrate with a master authentication scheme that passes back a unique key to the application to indicate a user has logged in via a third-party site.
2. Must be able to use existing user/roles tables.
3. May use forms authentication and allow users to log in via a separate login page if they aren't members of the third-party site.

I've tried customizing the SQL Role and Membership Providers, but I run into issues, particularly that there is a strongly-typed MembershipUser object that has a uniqueIdentifier (providerKey) and doesn't have room for my own custom set of keys (there will be two) that identify users.

Should I scrap my custom membership provider implementation and just go with cookies/session instead? I'd really like to use the built-in functionality but it doesn't seem doable.

Answer 1

What you might want to do is to build your item 1 over the top of the existing functionality, try that first. With the information returned, automatically log the user in. If the first process fails, do the standard authentication using the built in code.

I have built this type of system on top of the ASP.NET membership provider many times for clients using DotNetNuke, it works very well.

Answer 2

Go for it, here's the source to the built in ASP.NET 2.0 Membership provider from Scott Guthrie's blog.

Answer 3

I succesfully ditched the membership provider and do not user it at all. I created a new IMembershipService interface and an implementation for that which handles the creation and verification of my web application's users.

I've created my own User model. This allows me to have a flexible role model inside my application. I am free to create contextual domain roles and decouple them from the actual user model.

It's really not that hard. Remember to salt your passwords etc. and read some security books.

You can still use FormsAuthentication with this approach.

Most systems that rely on the asp.net membership provider are really schizophrenic in a way. You will have 2 Users table, for instance in CommunityServer you have aspnet_users and cs_Users where cs_Users references the MembershipId of aspnet_users and where it introduces yet another UserId. It also mirrors the username etc.