ASP.net Web API 2 controller with multiple authentication filters

Question

What is the intended semantics for multiple authentication filters? It is allowed? and if so, how do they work together?

Here is a specific example. Suppose I have a controller class such as

[BasicAuthenticator]
[LocalAuthenticator]
[Authorize]
public class TestController : ApiController
{
    [AllowAnonymous]
    public IHttpActionResult GetProduct(int id)
    {
    }

    // etc. etc
}

in which BasicAuthenticator and LocalAuthenticator implement IAuthenticationFilter.

Each authenticator will get a chance to succeed. If either succeeds, it will set the context.Principal to a new object with an appropriate ClaimsIdentity (name, type, and isAuthenticated = true).

What if an authenticator fails? I think it should do nothing, so that the other one will get a chance to succeed. Right?

And what if both succeed? Does whichever goes second erase the Principal created by the first? Wouldn't it make more sense to merge the ClaimsIdentity collections of the two Principal objects together?

If an authenticator fails, it should do nothing, Correct? Because the other authenticator might succeed. The semantics of having two authenticators is that the action will run if either one succeeds, Correct?

I think the Authorize class will look at all the ClaimsIdentity in the principal, and if any ClaimsIdentity has "isAuthenticated = true" then it will allow the controller action to run. Otherwise, it will set the status = 401. That seems to be how it works. It that correct?

The purpose of the [AllowAnonymous] is to disable all other authorization filters, correct? The controller (or action method) is decorated with [AllowAnonymous] then I assume that it should always run, even if the authentication fails. Is that correct?

Answer 1

With the recent Authentication filter introduced in Web API 2, I guess one is supposed to introduce one attribute for authentication, and possibly one attribute for authorization, as MS team split those two concerns. So the semantic is to have one for authentication.

It seems to me that the fact you can add more than one authentication attribute is just a coincidence, because you happen to set filters on controllers and their actions by means of attributes, and as you can add more than one attribute... Same goes with setting authentication filter project-wide, on all actions of all controllers: because one can add more than one filter, it does not necessarily implies that one should add more than one authentication filter.

If you need to support more than one authentication mechanism (e.g. a Basic and Local), you could just have one single attribute/filter that intercepts the request and that will try both mechanisms, implementing whichever AND/OR custom logic you might need.