ASP.NET Membership: to be or not to be?

I'm contemplating how I should implement authorization and authentication with ASP.NET and MVC2. Lets refer to this as a user system.

I have seen three types of solutions in the wild:

• Use the built-in ASP.NET Membership system (NerdDinner)
• Roll your own (Shrinkr)
• Create an abstraction layer for the ASP.NET membership (Tekpub's mvcstarter kit)

I've been reading your knowing thoughts and many say that trying to roll your own "user system" might be even dangerous, if you are not careful with the security details. On the other hand, the solution is a whole lot simpler. Everything is probably stored in one database and user specific stuff is in one users table. The overhead for this solution seems to be quite low.

Using the ASP.NET membership solution allows to use a lot of out-of-the-box functionality, but IMHO, is really confusing. You probably need to store the membership stuff in its own database and somehow be able to link the user entity from your site specific database to the ASP.NET one.开发者_如何学Go

If you are using the ASP.NET membership

• How does your database schema look like? How do you create foreign relationships to the ASP.NET membership users (ie. Songs <=> FavoriteSongs (<=> SiteUsers) <=> aspnet_Users)?
• Why didn't you roll your own?

If you have rolled your own

• What kind of user system abstraction layer, if any, did you use?
• Why didn't you use ASP.NET membership?

I'm really paralyzed by analyzing these possibilities. Please kick me in the right direction from this sticky web of membership paralysis! Thank you.

the built in membership provider is already secure and is really REALLY easy to use. You can be up and running with built in membership in a couple of hours. Alternatively (depending on what type of application you're building) you could also check out using OpenID which is what StackOverflow uses.

Also, with the built in Membership Provider, creating relationships is as easy as using a "uniqueidentifier" to relate the aspnet_User table (I can't remember the exact name off the top of my head) with the related table.

I store all of my membership "stuff" in the same database as the system db, and it has never steered me wrong. Creating the membership "stuff" is easy as well. Just run the aspnet_regsql.exe against the database that you want to have asp.net membership

Here's another SO question along the same lines.

Many people choose not to roll their own authentication systems for good reason! It's quite dangerous and there are many small ways you can get it wrong and leave your site open to attack.

I, however, am one of those risk takers and did roll my own. I double and triple checked every line of code for a security flaw and so far I've not had any security flaws patched since I released 1.0 of my authentication system. Anyway, my authentication system is named FSCAuth and BSD licensed.

• What kind of user system abstraction layer, if any, did you use?

I'm not quite sure what you mean. I basically have one layer where user data is retrieved and written to/from the database. One layer where FSCAuth actually deals with the cookies and HTTP authentication. And, one layer where you tell FSCAuth that "hey, this page should only be seen if the current user is in the Admin group".

My UserData class is quite simple with only 4 fields being required: Username, PasswordHash, UniqueID, and Salt. This is what FSCAuth depends on. If you need more fields, you can inherit form the UserData class and it'll work just the same.

• Why didn't you use ASP.NET membership?

I found so many short comings in the built in ASP.Net authentication

1. A lot of code must be written if you want to use anything other than the built in membership provider
2. Sometimes you have to deal with cookies yourself, which I'd say is dangerous
3. Nearly impossible to use the Blowfish hashing algorithm
4. Multiple round trips to the database for each page load
5. Stateful sessions (when a user logs in, a record gets put in the database) making it more difficult to expand to multiple servers and generally puts more unneeded stress on your database server.
6. Fine grained authentication(can see Person A's email, but not Person B's) is more difficult than I'd like
7. GUIDs

Many of these problems are by design and I believe are a symptom of trying to make one piece of software that will satisfy everyone.

Well, in FSCAuth I left quite a bit of things out by design, and honestly there is no way it's suitable for everyone.. but it's much easier to use than ASP.Net membership in many common scenarios. Can use just about any hashing algorithm under the sun. A single database hit for authentication. Stateless logins. A unique ID can be anything that'll fit in a string. Etc.

So if you're stuck in the decision between working around ASP.Net's built-in authentication and rolling your own, give FSCAuth a look first. If nothing else, it makes a great starting point for rolling your own.