ASP.NET MVC2 and MemberShipProvider: How well do they go together?

Question

I have an existing ASP.NET application with lots of users and a large database. Now I want to have it in MVC 2. I do not want to migrate, I do it more or less from scratch. The database I want to keep and not touch too much.

I already have my database tables and I also want to keep my LINQ to SQL-Layer. I didn't use a MembershipProvider in my current implementation (in ASP.NET 1.0 that wasn't strongly supported).

So, either I write my own Membershipprovider to meet the needs of my database and app or I don't use the membershipprovider at all.

I'd like to understand the consequences if I don't use the membership provider. What is linked to that? I understand that in ASP.NET the Login-Controls are linked to the provider. The AccountModel which is automatically generated with MVC2 could easily be changed to support my existing logic.

What happens when a user is identified by a an AuthCookie? Does MVC use the MembershipProvider then?

Am I overlooking something? I have the same questions regarding RoleProvider.

Input is greatly appreciated.

Answer 1

Although you most likely can do this without a custom membership provider, I'm not sure that you save that much effort. Until I read this blog post I thought implementing one was hard, but it's really not. Basically you do this:

1. Create a class that inherits System.Web.Security.MembershipProvider.
2. MembershipProvider is an abstract class, so you are readily shown what methods need to be implemented.
3. The names are pretty self explanatory, so you can probably more or less copy your existing logic.

You might end up doing more than you need with this approach - but on the other hand, anything you might want to use now or in the future that requires a membership provider will already have its needs met.

Answer 2

The source of the SQLMembershipProvider is available here http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx. Take that as a base.

It looks a bit much at first, but you only have to implement the methods you need.

Yes the AuthCookie is used. Yes its a good idea to use the MembershipProvider, because it is well known by other developers.

There are thinks I dont like about it: For example It is not possible to have a transaction that spans the creation of a user by the membershipsystem and some other data in your own datbase. But still it works well.

Answer 3

With MVC it is simple to bypass the Membership and Role provider framework altogether. Sometimes it is easier to do this than to implement custom Membership/Role providers, in particular if your authn/authz model doesn't quite fit the mold of those providers.

First, you should realize that you don't need to write everything from scratch, you can use the core Forms authentication API, which can be used independently of the Membership/Role provider framework:

• FormsAuthentication.SetAuthCookie - Call this after user has been authenticated, specify the user name
• Request.IsAuthenticated - Returns true if SetAuthCookie was called
• HttpContext.Current.User.Identity.Name - Returns the user name specified in the call to SetAuthCookie

So here is what you do in MVC to bypass the Membership/Role provider:

1. Authentication: In your controller, authenticate the user using your custom logic.If successful, call FormsAuthentication.SetAuthCookie with the user name.

2. Authorization: Create a custom authorize attribute (deriving from AuthorizeAttribute) . In the AuthorizeCore override, implement your custom authorization logic, taking the user in HttpContext.Current.User.Identity.Name and the roles defined in the Roles property of the AuthorizeAttribute base class. Note you can also define properties on your custom authorization attribute and use that in your authorization logic. For example you can define a property representing roles as enumerated values specific to your app, instead of using the Roles property which is just a string.

3. Affix your controllers and actions with your custom authorize attribute, instead of the default Authorize attribute.