How do you implement an ASP.NET role provider?

Question

I've got a few top-level questions about ASP.NET Membership and Role providers. I've done some searching but am having a hard time finding some layman tutorials. I have been coding in ASP.NET for a while now but the only real experience I have with authentication is the use of FormsAuthentication.SetAuthCookie(usernameFromDatabase, false);

When I use the SetAuthCookie() method above am I using the ASP.NET Membership Provider? Correct me if I'm wrong please but I don't think I am. I am just setting an authentication cookie right? I usually implement my own custom methods in my data repositories like GetUser_ByUsername(string username) which then talks to the ORM and gets the right user.

1. Do the Membership and Role Providers have their own data storage?
2. What if I want to use my own data storage?
3. Do I need to implement my own membership/role provider, and how would one go about doing that?
4. Or is my way of just setting the auth cookie and then using my own retrieval methods, etc, the best way of doing a custom membership/role provider?

I'm just looking for a brief tutorial/explanation of this system. If you have any good references for me to look at I will happily take a look :)

Answer 1

Implementing a membership provider is not too hard. Note that you only need to implement the methods that you plan to actually use. The membership provider should be viewed as a means to interact with your user information from an authentication perspective. It won't create the auth cookie for you; you do that after a successful call to the ValidateUser method on the provider. It will allow you to develop an application against the provider interface and easily change which provider you want to use via configuration rather than rewriting the application code. I've successfully implemented several different membership providers, using my own schema, which support built-in and hybrid built-in/active directory authentication. More info available via the links below:

• Article: http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
• Sample Implementation Description: http://msdn.microsoft.com/en-us/library/44w5aswa.aspx
• Sample Code: http://msdn.microsoft.com/en-us/library/6tc47t75.aspx

Answer 2

SetAuthCookie() works with the Forms Authentication framework within ASP.NET which you can then adapt for integration with a membership provider.

• Do the Membership and Role Providers have their own data storage?

They can, yes. There is an abstract implementation that you can subclass for your specific data needs. There is a SqlMembershipProvider you can use right out of the box, you just need a database to point to and create the needed tables. There is quite a bit of information on that class, like here or here.

• What if I want to use my own data storage?

The SqlMembershipProvider does, but check out this alternative MySQL framework if you're interested in seeing how another DBMS does it.

• Do I need to implement my own membership/role provider, and how would one go about doing that?

Using the built-in ones is pretty easy, but a lot of shops roll their own so that they can use existing tables. You'll need to implement this class.

• Or is my way of just setting the auth cookie and then using my own retrieval methods, etc, the best way of doing a custom membership/role provider?

In all likelihood you'll need a stronger system, and a custom membership provider is a good idea.

Answer 3

1 - Yes, if you use the built in membership/role providers they use tables created either in a separate database or an existing one. You use the tool aspnet_regsql.exe to create these tables - it walks you through a wizard. Alternatively, it can also be called from the command-line with different arguments in order to skip the wizard. This is some info from MS about creating the necessary DB/tables within your DB.

2 - You can do that, but you have to implement a custom membership provider, which isn't really difficult. Here and here are some tutorials.

3 - You don't necessarily need to unless you either want to use your own data stores or you need functionality from it that isn't present in the built-in providers.

4 - I would say you're better off using the built-in functionality ASP.NET provides for membership and roles.