I'm creating a custom authentication service (I just need more than the default allows). I can't decide if I should extend MembershipUser and implement the appropriate interfaces, or completely roll my own. Is there any advantaged to rolling my own, or any pitfalls I should be aware of when extending the default mechanism?
A:
Implement MembershipProvider abstract class. I have an implementation with XML as datastore right here, if you need it.
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx?queryresult=true
mare
2010-02-18 21:01:21
+2
A:
How far from defaults are you?
If your needs are far apart from what MembershipProvider gives you, I suggest you go with your own. I personally haven't come across an application that connected to an existing data store. So we would be adding another application to it. Hence I find MembershipProvider way over engineered. Authentication/Authorisation usually also doesn't take too much time to develop and you control it completely. If it does take a lot of time it's probably also far from what MembershipProvider gives you.
But if your requirements are close to MembershipProvider, then you should consider it. Either as it is or derive from it on your own. But beware. This may take more time than delivering your own, because you will have to learn it through and through.
Security management requirements
If you go with MembershipProvider (or your own inherited class) you also get IIS integration so it's easy to manage security settings of your application. If you roll your own, you'll have to provide an interface for that as well which may take a considerable amount of time.
Robert Koritnik
2010-02-18 21:08:14
Honestly, I wish someone would roll a more lightweight open source option. I really can't stand ASP.net membership
Matt Briggs
2010-02-18 21:12:20
@Matt Briggs: me neither. ANd saving XMLs in DB is just as stupid as it sounds. When you have DB to store data in, why handicap yourself?
Robert Koritnik
2010-02-18 21:25:25
here is an lightweight xml provider, if anyone is curious http://madskristensen.net/post/XML-membership-provider-for-ASPNET-20.aspx
mxmissile
2010-02-18 21:31:51
That's what I thought. XML provider with XML files on disk, not saving them to DB. Actually the one by Mads is great.
mare
2010-02-18 21:39:31
I'm not even just talking about the provider, the whole damn API is far too complex for most cases. Not to mention that implementing your own provider is a royal pain. There are about 30 required methods, and anything else you need to do not covered by their API requires casting Membership.Providers["yourName"] to your Type to access. I don't want to plug into a crappy auth system. I either want something that plugs into MY api, giving me auth related stuff for free (like password hashing/salting/resetting/etc), or an out of box solution using code generation or partials to allow customizing
Matt Briggs
2010-02-18 22:07:35
@Matt I know exactly what you mean. I got really frustrated when I realized it would be near impossible to create a user with more than a password and e-mail.
C. Ross
2010-02-25 18:33:48
A:
Its always good fun to write your own provider but it depends on the security needs of the application you are building.
Most occasions when I have had to implement my own provider.
- Using an orm such as nhibernate.
- No database so requried to use flat xml files.
- I had to build a system that required a more extensive role-permission system than the membership classes provided.
Good thing is you can switch between different providers if you need too..
Aim Kai
2010-02-18 21:14:16