Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there are any specific rules and regulation to follow while developing a custom membership provider. Like, implementing a particular Interface or Abstract class. Or a definite model architecture to follow.

If yes, then what are the rules or I am free to design, model and code anything ?

share|improve this question
up vote 1 down vote accepted

First rule is don't reinvent the wheel -- the built-in SQL membership provider is quite good, especially at pure membership stuff. If you treat it as a black-box authentication scheme you can build just about anything on top of it. There are very few good reasons not to use it.

If you must, the whole provider model has some pretty specific requirements, you can read about implementing a membership provider or check out an example ODBC membership provider.

share|improve this answer
I have read the msdn articles. My basic concern was if I am implementing one myself should I follow some regulations like implementing a particular Interface or abstract class or else my membership provider won't work – Pankaj Upadhyay Sep 23 '11 at 12:39
I'm really not sure how you read the articles and didn't get that you must implement certain abstract classes -- that is part and parcel with the entire concept of the Provider model. – Wyatt Barnett Sep 23 '11 at 12:42
Thanks mate.... – Pankaj Upadhyay Sep 23 '11 at 12:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.