Authenticate in the Services? Or in an Endpoint that exposes the Services?

Question

When I'm in charge, I typically model services separate from endpoints. For example: Company.Project.Domain.dll has all of the logic required to complete the services for that domain. In order to access it you either reference that library or, if I'm exposing the services through an endpoint, you can hit Company.Project.Endpoint at the URL: api.wutevz.com/blog/Message/

I mention the above because I have (seemingly unfortunately, but maybe I'm the wrong one) seen the majority of services/domains created directly inside an endpoint project (like WCF or Web API). And knowing my setup is key to my question. Also, if separating the logic from the endpoint is weird, feel free to chime in. While I think separating them is correct, I'm jaded from many years of consulting and seeing them joined.

The question, if my methodology is sound, is: Where should Authentication Live in the backend? This is unrelated to other questions asking if it should be in the backend vs the client. My question is: On the Endpoints, or on the Services?

So my Web API has this Endpoint:

[HttpPost]
//[AuthenticatePlz]
public HttpResponseMessage Message([FromBody] string contents){
    _service.AddMessage(contents);
}

And some domain service has the method that does the real biz:

//[AuthenticatePlz]
public void AddMessage(string contents) {
    // probably do some content checks or something and save the message
}

Don't get too hung up on whether Aspects are being used, or some Owin middleware, or Line 1 of the method is an Auth call, or some other horrible implementation. The goal is: Should the interception point, where Authentication is required, live on the Endpoint or the service method?

Answer 1

Ideally authentication should happen neither in the end point nor the service. A module in IIS or a proxy server would be best, or a plugin to the application framework. If you must intermingle the two I would put the authentication in the end point. A "service" object should assume you have permissions to use it so it retains maximum reusability.

Really the end point should also assume you have permission to operate on it. Something higher up in the stack should prevent your end point object from executing if authentication fails. This way changes in permissions or authentication schemes don't require changes to your end point or service layer.

Answer 2

If I'm not mistaken, ASP.NET Web Api handles authentication using the IPrincipal interface.

A principal object represents the security context of the user on whose behalf the code is running, including that user's identity (IIdentity) and any roles to which they belong.

This object is basically a set of Claims which defines and describes the current user. That is, its username, email, and even roles.

Wether you're using a middleware or not, these claims have to be set so the authentication can be integrated in the IIS pipeline.

In a web service example like yours, these claims are commonly decoded from an authentication token. This token is sent along the user request, and therefore should be handled at an endpoint level (Controller).

Your domain service should not have to inspect the current request context, nor it has to know it's being called from a web service, or a desktop client.