What are the pros and cons using the asp.net membership?

Question

I'm building a new website and a friend suggest to me to use the asp.net membership for the authentication process (login, registration, password recovery, etc..).

I saw that everything is stored in an XML file.

I would like to know what are the pros and cons using the membership instead of to build something from scratch.

Answer 1

The MS login solution consists of several parts.

Authentication - "Who can access your site"

Forms Authentication - This basically creates a secure cookie that says "I'm authenticated!" on every request. Without this, users would have to log in every single page.

• Pros: This works well
• Cons: None - use it

Membership - This is how you store your users and their passwords, and validate user credentials. There are several ways to approach this:

1. Using the SqlMembershipProvider - Microsoft gives you a database to store users/passwords in securely, and gives you a way to authenticate credentials.
   • Pros:
     • Less/no custom code to maintain. Works "out of the box"
     • Works with Membership controls and API
   • Cons:
     • You have to use a Sql Server and use their database schema. (not a problem IMO)
     • No control over how passwords are initially generated. They're long and ugly
     • Steeper learning curve as you get familiar with the technology

2. Creating a custom MembershipProvider - You can inherit from MembershipProvider to customize where and how you store your data.

   • Pros:
     • You get Encryption/Decryption of passwords for free
     • Control over where you store your users and what the data looks like
     • You can still use the Membership controls and API
   • Cons:
     • Have to implement your own storage solution
     • You have to write, debug, and maintain a lot of custom code
     • If you add additional functionality, you have to cast the provider to use it

3. Creating your own Authentication scheme

   • Pros: Complete control
   • Cons:
     • You create everything, but have to debug/maintain everything.
     • You have to control security over credentials yourself.
     • Can't use Membership controls (This isn't a big loss as the controls are pretty simple to replicate)
     • Can't use Membership API

Authorization - "What can the users do?"

Roles - Roles control what the users can do via the authorization mechanism provided by the web.config and also works with security trimming on the sitemap.

1. Using the SqlRoleProvider - Microsoft gives you a database to store roles

   • Pros:
     • Works with the web.config
     • You can assign more than one role to a user
   • Cons:
     • Roles are just a string, no "hierarchy of permissions" support. This can make it difficult to create rules around which users can edit other users.

2. Creating a custom RoleProvider - You can inherit from RoleProvider to customize where and how you store your data.

   • Pros: Works with the web.config
   • Cons:
     • Have to implement your own storage solution
     • Still just a string and are as limited as the previous solution
     • If you don't implement it correctly, it could do a lot of database calls.

3. Creating your own Authentication scheme

   • Pros: Complete control - Just do custom checks on your page and error/redirect as necessary
   • Cons:
     • Doesn't work with the authorization mechanism provided by the web.config / sitemap. Practically this means that adding a page to a folder (such as /Admin) no longer guarantees security on that page.

---

It's important to note that the Membership and Role providers can be chosen or customized independently of each other. I would personally recommend using the SqlMembershipProvider if you can and evaluating your options for the Role Provider.

Answer 2

I dont like to use Membership Provider.

This is util when the scenario is "standard", but in cases that you need more custom rules, I think that dont works well. Appear "workarounds".

And not need store in a XML, exists another solutions (database, for exmaple).