What are the advantages of a custom MembershipProvider in ASP.NET?

Question

If I need to implement my own MembershipProvider class, I have to implement all the services I require myself, so what advantage do I gain by implementing a MembershipProvider derived class versus just writing my own MySecurity class?

Answer 1

Well, it depends... I found it very useful because I had to add the concept of functions, so that every role had functions associated to them, and so forth.

In that case I implemented my own Membership and RoleProvider classes which contained the AddFunctionToRole method... IsFunctionAssignedToUser method... etc etc

A little more info on that here

Answer 2

The main advantage of writing your own MembershipProvider class is that it's considered by the ASP.NET as a first-class component and you can use the standard interfaces for authentication and authorization and only have to change the config file afterwards if you want to use a different provider.

Answer 3

Getting an authentication system right is hard, because it's so easy to build something that only appears to work. You don't want to find yourself in a situation where a year after deployment you finally discover your system was cracked six months previously.

Building your system using the MembershipProvider model helps you do it right by giving you a skeleton that lends itself to being implemented correctly. You only need to accurately fill in a set of methods, and you can rely on the high-level architecture provided to make sure you are using the right methods in the right places.

Getting individual method implementations done right is comparatively easy. You can put those into your unit test and have confidence that they do what they are supposed to.

Put another way, you don't have to worry about whether you check your authentication token in the right places. The parts of ASP.Net that call into the membership provider know when to do that. All you have to do is correctly implement the check, and that normally comes down to a simple comparison.

Additionally, you may not need to start from scratch. You have to option to inherit from an existing provider and only add the functionality you want that it doesn't already provide.

Answer 4

If you just need something a "little" different from one of the default membership providers then you should probably just consider inheriting from one of the built-in providers or one of the better 3rd party providers and extend it with the additional functionality that you need or override the functionality that you want to change.

Answer 5

Technically, you should gain some level of portability - by using the existing model, you should be able to drop your provider into other web applications, to replace their membership system with very little effort.

Unfortunately, the number of 3rd parties out there who seem to have gone their own way when it comes to membership/profiles is quite impressive, and also rather depressing, especailly when you've put all the effort into writing something based on it.

That being said, by using the membership provider model, all the other controls that use membership "just work" (i.e. Login, LoginStatus, LoginName, etc) without having to write custom versions of those as well.