Support multiple authentication mechanisms in a single application

[hantsy]

For example, in a Jakarta web application, it includes web pages for administrator and also provides Restful APIs for client applications.

We could use FORM to protect the web pages(/web), and JWT for the Restful APIs(/api).

1. provides a Spring security equivalent securityMatcher(accept ant pattern or regex pattern, provides an extra attribute to accept a custom PathMatcher bean via EL) like attribute in the current annotations to filter out if the request path is matched. If it is not matched, skip the authentication quickly.
2. Reuse @Priority annotation to order them at runtime.

[OndroMih]

I created this proposal as a possible solution to this: jakartaee/security-examples#11.

The core idea is to make it possible to choose programmatically which of the built-in authentication mechanisms should be used based on configuration or user input. It would be possible to inject one or more mechanisms configured using the existing definition annotations (e.g. @BasicAuthenticationMechanismDefinition) and delegate authentication to them from a custom HttpAuthenticationMechanism bean.

Then it would be possible to choose between multiple mechanisms based on info in the request, e.g. URL, query parameters, cookies, etc. We can extend it by some helper functionality, e.g. to have a simple mechanism to select from the injected mechanisms using URL pattern matching, etc. Any suggestions welcome.

[arjantijms]

See this existing issue: #188

Also note this was discussed extensively discussed during Security 1.0. There is a 3D matrix for different authentication mechanisms:

1. Having different mechanisms per URL
2. Having different mechanisms cooperate on a single request (typically, if A fails, fall back to B)
3. Letting the user choose an authentication mechanism

[OndroMih]

I didn't see the original issue. I commented there now too: #188 (comment).

My proposal would address the points 1. and 3. from the above. Actually, even 2. could be implemented, because a custom auth mechanism could call a built-in mechanism, and based on the result, it could call another auth mechanism. I believe my proposal is very light-weight, doesn't add any new API, and leaves a lot of power on the implementor of the custom auth mechanism. Without this, it's impossible to combine the built-in mechanisms in any way, because when a built-in mechanism is enabled, no other mechanism can be enabled with it.

[darranl]

I can't remember exactly how it was presented around 2016/2017 but in WildFly with WildFly Elytron we are definitely using the phased approach.

In the first phase the configured mechanisms are given an opportunity to authenticate the incoming request, if that is not successful and authentication is required the mechs are then all given an opportunity to participate in generating the response so multiple mechanisms can challenge.

[OndroMih]

I can't remember exactly how it was presented around 2016/2017 but in WildFly with WildFly Elytron we are definitely using the phased approach.

@darranl , are you talking about the distributed realm in Elytron? https://wildfly-security.github.io/wildfly-elytron/blog/distributed-realm/

If not, can you give me some pointers where to look to understand what is implemented in Elytron?