Why should I Use ASP.NET Membership security model?

views:

995

answers:

+11 Q:

Why should I Use ASP.NET Membership security model?

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 which is included in ASP.NET but I'm convinced that it will provide any benefit apart from being familiar to other .NET deevlopers.

There seems to be quite a lot of documentation for it, but little discussion for why its worth the effort.

Can anybody shed some light upon this?

+1 A:

It is there simply so that you do not have to roll your own.

Chris Lively 2009-01-13 20:14:18

+2 A:

This link will give you a lot of matter trying to convince you the advantages of the ASP.net membership provider. All I would like to say is that it fits well with most of .net solutions be it web, windows client etc. Also you may tweak a few things and roll your own provider. If the pants dont fit to your style, get one tailored !

Perpetualcoder 2009-01-13 20:14:49

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.

Craig 2009-01-13 20:15:04

+3 A:

Unless you are the only person who will ever work on this particular site, I think the fact that it is familiar to .NET developers is a good reason to go the built-in Membership route. Other developers with ASP.NET experience can jump into the project and get up to speed on your site's authentication/authorization model very quickly.

We use the built-in Membership and Role provider model on our site and it works very well...we had to write our own Provider classes, since we use a different backing store for the data (we use Microsoft Dynamics CRM), but these classes are pretty simple and well-documented. By doing this bit of work up front, we can now use the Membership and Roles classes in code as well as the various login-related server controls on our pages.

Is there another alternative that you are considering?

Matt Peterson 2009-01-13 20:15:26

Hmm so how does the User, IPrinciple and MembershipUser all relate?

ListenToRick 2009-01-13 20:32:25

User (I assume you mean the Page.User property) works just as before: it returns an IPrincipal; specifically, an instance of RolePrincipal. Because we wanted to track additional information about each user, we derived from MembershipUser as well. We can call (OurMembershipUser) Membership.GetUser().

Matt Peterson 2009-01-13 21:16:05

So Membership is not the same as MembershipProvider ?

ListenToRick 2009-01-13 21:51:22

Not exactly; Membership is a static class that exposes a number of membership-related methods (e.g. CreateUser(), DeleteUser()) which in turn call the current membership provider class defined in the web.config file. More details: http://msdn.microsoft.com/en-us/library/2d449f1x.aspx

Matt Peterson 2009-01-14 00:33:04

If you ever want to migrate your site to any kind of already made portal software - like Community Server or DotNetNuke using the membership provider allows for easy migration. You can even use the existing database and not have to implement new ones.

RideSearch.com 2009-01-13 22:04:01

+1 A:

The only think I really hate about the MembershipProvider that comes with .Net is the fact that the userid is a GUID instead of an auto incrementing identity. I know there are bonuses to using a GUID but integrating it pre-existing systems or modules can be a pain.

Al W 2009-01-13 22:10:21

I think that's a major reason for using guids. At some point, while integrating two systems, you may have duplicate user ids if they are auto-incrementing ints, but (in theory) you'll never have duplicate guids.

domus.vita 2009-01-14 13:37:30

+1 A:

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.

alchemical 2010-04-17 01:05:59

+1 I really don't get the fixation with it.

Hightechrider 2010-04-17 01:53:12

IMO, this is a ridiculous comparison. You might as well be claiming that Membership Server is the same as AD. The MembershipProvider functionality and Membership Server work on entirely different technologies. The MembershipProvider will scale to whatever you db or AD store can handle. If you ever get to the point of actually hitting some upper limit in performance (unlikely), then write your own MP.

Thomas 2010-04-17 02:22:13

The effort to write a custom MP would appear to be roughly the same effort to write a completely custom solution. By going completely custom, the total amount of code at the end in the system will be about 20 times less, maybe 50 times less.

alchemical 2010-04-17 02:37:03

+1 A:

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 add salt and encrypt your passwords, and do a proper encrypted cookie please.

Hightechrider 2010-04-17 01:44:44

Glad to hear someone else decided to go this route. Do you mean encrypting the password for storage in the DB or something else? Any recomendation for the best way to encrypt the cookie?

alchemical 2010-04-17 02:42:32

To create authentication token: Add an expiration date, Triple DES encrypt then Base64 encode using URL safe characters. Using URL safe Base64 encoding means you can also use them on query strings. I've been meaning to write a blog entry on my LINQ-to-EF based authentication scheme for some time ... maybe I'll make the effort now.

Hightechrider 2010-04-17 02:53:05

ansaurus

tags:

views:

answers:

Why should I Use ASP.NET Membership security model?

related questions