How can I implement an ID based user system (membership, authorization, etc.) in ASP.NET MVC?

I have been thinking for a good while about how to tackle the problem of implementing an ID based user system while using ASP.NET MVC. My goals, much like StackOverflow's system are as follows:

• Allow the users to change their nicknames without the "avoid duplicate" restriction.
• Allow the users to authenticate via OpenID (not with开发者_如何转开发 password for the time being).

I wanted to avoid as much rework as possible, so I at first thought of using the membership, role and (perhaps) profile providers, but I found they were username based. I thought of adapting the hell out of the SqlMembershipProvider, by using the username field to store the IDs and throwing UnsupportedException on password based methods and the like, just so as to be able to use the other systems. But it feels unwieldy and kludgy (if possible to do at all).

On the other hand, maybe I should roll up my own user system, but I'm not sure if even if I can't use the providers, I can still use some of MVC's features (plug my code in with MVC somewhere, I can think of AuthorizeAttribute off the top my head).

So I was wondering if anyone had run into the same design problem, and what solutions they had come up with.

The more detail the better!

I had to set up a quick membership system for a client, they had some requirements that didn't allow me to use the built-in right off the bat nor the time to build what they wanted. I have plans to eventually roll-out a complete membership management system, but like you, I needed something now. I went with the following plan, which will, eventually, allow me to swap out the built-in providers for my own - time constraints and deadlines suck:

I have my own Personal User Table (PT) - MembershipId, UserName, Email, superflous profile info. This is what the app uses for any user information. It's a class, it can be cached, saved in the http context, cookie - however you want to handle your user info.

I then set up the SqlProfileProvider for authentication, authorization, and roles. I don't use the profile provider (even for trivial settings) because it's a pain in MVC. I made no changes to the built-in providers. This is what I'm using for authentication and authorization.

When creating a user, my code does the following:

1. Check PT for user name and email, per my rules
2. Create Guid - MembershipId
3. Create MembershipUser, the MembershipId is the username (the email is irrelevant and not used), and user password, question and answer, etc.
4. Create the user in PT with the profile values and use MembershipId as the PrimaryKey.

On login, I get the MembershipId from PT, validate against Membership with the MembershipId and the password and I'm done..

When deleting a user, I do the following:

1. Check PT for user, make sure I can/should delete
2. Get MemberShipId
3. Use a transaction
4. Delete from PT
5. User Membership.DeleteUser(MembershipId, true) - this ensures that the user is deleted from teh membership and other aspnet_ tables
6. commit

And it works as expected :)

A few things: User.Identity.Name will be the MembershipId (Guid). This is used for SignIn and Role management. My PT is where the user's info (save the password) is saved. I can change user names, emails, etc with no impact on Membership or Roles because Membership is based on the PrimaryKey from PT.

The signin requires an extra DB hit because you need to query PT to get the MembershipId to validate against (you could cache).

The built-in auth system is really heavy - if you look at the sprocs you will see all the hoops it goes through to validate a user. I'd recommend eventually getting away from it. But in a tight spot, it does a good job - and if you don't have a milion users, I don;t think it'd be a problem.

I didn't consider OpenId and I'm not sure how you would integrate it, although I think you could probably do the same thing as above and instead of validating against actual credentials (after they come back validated form OpenId) just log in the user using the MembershipId (don;t validate against Membership).

For me, the main point behind this was that the app uses a custom user model, allowing for changes to user name, email, names, etc. Without impacting the auth and roles. When I am ready to change to the complete system, I can change it without worrying about the impact to the app.

Kenji,

I would recommend looking at some of the existing OpenID providers for ASP.NET. It should be fairly easy to make them work with MVC.

Erick

Forgo the use of SqlMembershipProvider. The only thing it would really offer you is an out of the box admin interface. The rest that it brings would be a nuisance.

Just use the sql membership provider and add a stored proc to change the username at the database level.