On Which Tier should user authentication should exist in n-tier website

Question

I went through different Architecture books such as this one: Microsoft Application Architecture Guide, 2nd Edition And now I am building a new n-tier website with ASP.Net MVC as Presentation layer. My question is, If I will use the asp.net Identity, on which tier/layer should I implement the user authentication?

I thought it should be in the Cross Cutting Concerns, because I will need to check if user is authorized or authenticated to access some functions plus I may use the user name on many tiers, such as the Business, Services and Presentation layer.

and also thought it will be better to put it in the Presentation layer specially because the presentation layer is MVC and it will be easy to deal with ASP Identity from there and will allow me to user [Authorize] and [AllowAnonymous] easily.

I know that this question answer depend on many other factors but I am trying here to achieve the most best practice, so need to get your point of view and discuss it.

Answer 1

There are quite a few similar questions here on stackoverflow, and just many answers. Here my view on the matter.

You have to separate the abstraction from the implementation.

The abstraction (an interface) defines the questions you need to able to ask to the authentication service. This interface is used by all other parts of your application that are going to use your authentication service. This means that your abstraction must be defined somewhere that can be referenced by the other parts of your application. My suggestion would be to put this in the business layer, since the methods in the interface (in other words the 'questions that you want to ask to the service') are usually business related. Another suggestion is to put it in a Core layer (if you have one).

That leaves us with the implementation of the interface. I would implement this in the easiest place that you can that works. Can you do it in the business layer, fine. Do you need to use the identity classes from MVC, good too, place it there. It doesn't really matter where you put it, since it isn't used directly.

Of course, to make this all work you do need to use a little Dependency Injection, to register your implementation for the interface.

Answer 2

I have found that this is usually a pretty straightforward answer if you separate the concern of authentication from authorization. Authentication always ends up having to sit in front of presentation. It's a layer in front of the presentation layer. It really has to be.

After authentication occurs, passing that authenticated identity down into the other layers is just another model object, and should be treated as such. Binding authentication/authorization to all the different layers as a cross cutting concern makes your code much harder to reuse in different contexts. Also makes it much harder to test.