Authentication in a multi layer architecture

Question

I am designing an N-Layer system in .NET that will consist of

• SQL Server 2008
• EF 4
• Repository Layer
• Service Layer(Business Logic)

On top of this I will have:

• ASP.NET MVC website
• external API to be consumed by other clients(built with WCF or ServceStack.NET)

I would like to implement the typical username/password auth within the MVC app as well as OpenID/twitter/facebook login options

The api will need similar forms of authentication.

Where in the architecture is the best place to implement the authentication and are any samples available of how to implement something like this with a .NET Stack?

Is a custom Membership provider an option for this?

I realize that there are libraries available to implement the openID portion so that is not a concern at the moment but I would like to leave things open to add this in the future.

Suggestions?

Answer 1

Authentication should be done at the user facing point: MVC website and the WCF service.

In each point, use the appropriate authentication/authorization mechanism.

MVC website : forms authentication (or windows authentication etc.)

WCF service : (what method will you be taking, API key, user/name password on every request, secure key, auth cookie etc.)

For each point, call the service layer with the credentials used by the requestor (user) and validate it against your database (in the service layer).

The service layer should return valid/invalid for the credentials given to it.

If it's invalid , have your website or webservice reject any further actions from the user and inform them that it's not valid.

If it's valid , have your MVC website create the auth cookie ( FormsAuthentication.SetAuthCookie ) and your WCF service do the appropriate action for the authentication mechanism you chose.

Keep your service layer agnostic of the authentication. It should only respond with whether or not a set of credentials is valid and your front-facing layers should take care of setting the authentication tickets.

For Open ID/Twitter/Facebook logins, all the information needed is on the web app (via the login source cookies), so use that to setup your website's auth cookie.

Answer 2

A basic architecture would be to use the asp.net membership api for your service and web apps calling into the same membership database. Then use an impersonated user to connect to SQL Server.

You can then write custom membership providers for the other auth mechanisms or incorporate them all into one membership provider.

Answer 3

Sorry had to write this as another answer as didn't have enough space in the comments.

Configure the membership provider at the IIS level and use the OOTB SQL membership provider to get basic authentication working.

You can then write a custom membership the repository layer will be running in the context of the web application either web service or asp.net site so your authentication information will be in the httpcontext, you can then use that to connect through to your database or use an impersonated account ie the app pool user to connect instead.

You can then write a custom membership provider that authenticates against the other providers if you like and just swap out the standard SQL one for your custom one.

Answer 4

As an addition to Omar's answer :

You could also use a Facade Pattern which handles the authorization and is used by both the WCF and MVC code and provides the API to the business layer.

A rule of thumb is: Put authorization at one single point and let the auth-logic be handled by the client(s). Don't spread it over your service layer!