Help me decide whether to use ASP.NET default membership/roles providers or write custom providers

Question

I spent a good part of yesterday reading up on the subject and still feel like I am uncertain which way to go. I come from a "roll your own" background when it comes to authentication and authorization. We never used Forms authentication, let alone the Membership API. Looking at our old code we would use session variables to capture/control whether a user is logged in etc. With this new project I am about to undertake I want to put us back on track with what we should have done to begin with, which is use the tools provided by the framework.

I already have a database schema that I'll be working with, however it's not set in stone; I am able to make changes to it if necessary. In this schema there is already a Users table, utilizing an integer as the primary key. This table also has other information such as First and Last names. I also have foreign keys based on the UserId to other tables such as Phone and Address. Below I outline some of the pros/cons that come to mind.

Default Provider

Pros

• Less code.
• Ability to utilize all of the associated server controls such as Login, ChangePassword.

Cons

• Some controls might not be usedful to me out of the box. For example the CreateUserWizard, I will need to possibly capture other information during user creation such as phone and address information to associated tables. Not sure if this renders this control useless to me.
• I'll have to create foreign keys in my associated tables (Phone, Address) to the UserId which is a GUID in the default provider.
• If I do create these foreign key constrains and not utilize cascade delete; I will need to also delete associated rows in foreign key tables. Potentially having to utilize something like a TransactionScope object to make sure all of this is an atomic operation.

Custom Provider

Pros

• Ability to utilize existing schema tables.
• Easier to extract authentication/authorization into a service down the line.

Cons

• Have to provide implementation to most/everything myself.
• To use any of the controls, I'll have to provide their required implementation in the provider.

There might be other things I have not yet considered, being that I never used this before which makes me a little uncomfortable as well.

Thank you.

Answer 1

I recently had to make the same choice and decided to go with creating a custom provider.

My biggest reason to do this came down to the default db schema. All of the default db objects are created in the dbo schema and are prefixed with 'aspnet_' or 'vw_aspnet', etc. For me it was a real turnoff. If you haven't seen them yet, run aspnet_regsql.exe to create them.

In addition, Steven Sanderson says this in Pro ASP.NET MVC 2 Framework:

...SqlProfileProvider uses an especially disgusting database schema, in which profile entries are stored as colon-separated name/value pairs, so it's basically impossible to query.

Overall, it's worth following the API because of the clear separation of concerns, reuse across projects, and integration with the rest of ASP.NET, but you'll only want to use the built-in SQL storage providers for small or throwaway projects.

I haven't gone through the entire process of creating the custom providers yet (I did do a partial implementation when I was playing with Azure Table storage), but I plan to use these providers over multiple projects in the future, so I feel the effort will be well worth it.

Answer 2

If you are building a new application I would not hesitate to use the asp.net default provider. you can always decide not to use the default controls and programatically create your own. you can also save a lot of time by using any opensource pre created user management tool. At the same time you can always extend the information contained into the default tables.