I\'m updating my website at the moment and figure that if I am to update my login/security mode, now is a good time.
I have looked through the Membership model whic
I think a compelling feature of ASP.NET Membership, Role and Profile is that it uses the provider model. If you aren't happy with it the way it is, it is not difficult to roll your own from the base classes. If you look at codeplex.com you can find probably a dozen or more custom providers that people have written. I wrote one for the SQLite database a few years ago.
It's value is that it is an easy to use ready built role based security framework. If you have already built your own framework and migration is not trivial then it may not be worth it. But one benefit of migrating would be you could eliminate a lot of application code and replace with framework code.
It is there simply so that you do not have to roll your own.
I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.
If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.
If not, build your own, but if you do, make sure you store an encrypted/salted hash of your passwords, and do a proper encrypted cookie please.
[Updated to reflect feedback in comments]
The Membership route works well BUT there is one fatal flaw and I do not blame Microsoft for it.
Internet Explorer is the only browser that properly disposes of the authentication cache.
You can close a Firefox browser, open it and then restore that last session and go right back into your "secure" website without logging in. Chrome has similar issues and anything Mac does the same.
IE has a javascript call that handles this correctly: document.execCommand("ClearAuthenticationCache", "false");
It does not work with any other browser. If you use this you need to force users to use IE.
I see little benefit to using membership for a large site. This has been marketed as 'the' solution for ASP.Net authentication. However, really it looks like Microsoft is just trying to position the old Membership Server product as soemthing that everyone all of a sudden needs.
I worked on Membership Server at Msft around 10 years ago. Was also a lead developer on shop.microsoft.com, and I can tell you we used no internal server products on that site--not commerce server, not membership server. Not sure how they are doing it now--but I think the general consensus at that point was that those type of packages generally got in the way of what we were trying to do.
It could be useful for a smaller site, or if you have limited resources... i.e. a few hundred users for a departmental or small company intranet, where you don't want to invest much time or resources. The more I look at it, the more it seems completely inappropriate for larger, custom web sites.
What I really don't understand is how almost every ASP.Net book seems to push this as the only way to do it, rather than one way to do it.