views:

153

answers:

1

For ASP.NET MVC extranet applications, what are the pros and cons of using SQL Authentication instead of the ASP.NET Membership API to handle security?

+1  A: 

Gern, you are describing aspects of the same framework.

The asp.net provider stack is an abstract service layer that 'provides' common services to your applications.

The built in Sql providers are simply implementations that use Sql server as a backing store. The MVC framework and scaffolding provide all of the necessary adapters for using the default Sql providers.

If the built-in asp.net sql providers provide the functionality you require then the pro is that all the work is done.

Not sure what a con would be.

In regards to the possibility that you want to compare using Sql providers vs AD providers:

The AD/Token based providers Active Directory for authentication and access control and the implication is that a user must have a valid account setup in the AD in order to access protected resources.

The Sql providers allow you to define arbitrary users that do not require AD accounts.

The infamous grey zone appears when you have a large AD user base that you must support but must also allow for non-AD accounts to be established. At that point you will start to explore the exquisite joy that building composite provider stacks will bring to your life while it steals your sleep. But that is a topic for another book.

HTH

Sky Sanders
Thanks. I guess I'm confusing the storage of logins in SQL Server (as actual SQL Server logins) with the storage of logins in a SQL Server Membership database.
Gern Blandston
@Gern - the only SQL login you will be concerned with is the one,if any, in the connection string. For a sandboxed/dmz type server you may have a static uid/pwd pair, but in a lot of scenarios the net admin can set up a limited trust between the dmz and the interal sql server to allow integrated security.
Sky Sanders