Introduce HttpAuthenticationMechanismHandler
Closed this issue · 2 comments
As an analogy to the IdentityStoreHandler, introduce an HttpAuthenticationMechanismHandler as an extra point for handling multiple authentication mechanisms. This construct can be used as the basis for the following requested features:
- Authentication mechanism per URL SECURIY #86
- User choice of authentication mechanism (login with provider X, login with provider Y, etc)
- Multiple authentication mechanisms (try JWT, fallback to BASIC, etc)
The HttpAuthenticationMechanismHandler will not provide details about any of these features, and the behaviour of the default implementation should be the same as the current behaviour in Jakarta Security (one allowed enabled HttpAuthenticationMechanism)
A handler is called by the system, and contains the algorithm for handling multiple mechanisms. Which is currently really simple - only 1 authentication mechanism is allowed.
The developer should not bothered by this handler. It's an optional thing of plumbing for the developer, which essentially standardises what the CDI extension for Jakarta Security implementations was already doing. That CDI extension had a bit of logic in it to only allow for one HttpAuthenticationMechanism. That logic is now officially delegated to the Handler, and not longer an implementation detail.
Like the identity store handler, the Jakarta Security implementation has to provide a default implementation of this.
I understand that this is not supposed to provide a solution to any of the existing issues or proposed usecases, but can be used as a building block for a final solution. E.g., with this, it's not possible to delegate to Form based auth for one URL pattern and to OpenID for another pattern, but once it's possible to inject the default form and OpenId mechanisms, then the handler could delegate to them based on the URL.
I support this PR, and I'd like to see solutions based on this, e.g. injecting existing auth mechanisms as suggested by #188, or programmatic configuration as suggested in #227
but once it's possible to inject the default form and OpenId mechanisms, then the handler could delegate to them based on the URL.
Indeed. That hinges on introducing qualifiers for the default (build-in) authentication mechanisms. This will be handled by another issue.