Best Practice for ASP.NET Security Authentication and Authorization

Question

What is generally accepted as the best practice for an ASP.NET site to implement security authentication and authorization that is not based on Windows AD and stores account information in a database? Is it to use the built in Forms Authentication, a stock or custom rolled MembershipProvider, the Enterprise Library Security Block?

Are there any pros and cons between them, such as replacing Forms Authentication makes it harder or not possible to protect directories with files that need restricted that aren't ASP.NET files?

Answer 1

Using Forms Authentication (with either the stock MembershipProvider or a custom MembershipProvider) is typically considered the standard.

Answer 2

Ouch that's a huge topic, so instead I'll list some general points.

Forms authentication gives you an authentication cookie separate from a session cookie, which is protected against tampering and can be encrypted. Its provider model means this protection still exists even if you roll your own membership provider and these providers can be used to protect WCF web services, and to allow authentication and authorization with silverlight

Forms auth also creates an IIdentity/IPrincipal object on the executing thread which means you can use CAS PrincipalPermission demands to protect methods, classes and even assemblies which can be separated from your ASP.NET application, making authorization the cross cutting concern it should be.

Forms auth is also used by IIS7's file protection mechanisms, and so can be used with IIS7 to protect any type of file, not just those which are associated with the ASP.NET ISAPI DLL (you can, in IIS6 do a wild card mapping and put everything through the ASP.NET pipeline, but that has an impact on scalability)

Forms auth does not allow impersonation.

Rolling your own removes all of this. You can start to build it back in using HTTP Modules which would do your own cookie loading and validation, creating the principal on the thread and checking access to resources. You'd still need to write the database bits, controls if you need them, your own classes and plumb them in.

And you'd need to get it right.

There are a lot of pros for the standard way to do it, and it's been hammered and tested and used and abused by a lot of people, the biggest con for rolling your own is you're probably not as clever as you think you are - I know I wouldn't do it.