BasicAuthHeaderAuthVerifier is capable of issuing challenges to the user-agent, but this is switched off through configuration because of the following reason.
If it is first in AuthVerifierPipeline then either it logs the user in, or it issues a challenge. Consequently PortalSessionAuthVerifier (and other AuthVerifiers) will not process, and no authenticated session is considered.
Similarly If PortalSessionAuthVerifier is first, then no session can be re-authenticated. The www-authenticate request header is essentially ignored.
The objective of this proposal is to remove this problem and encourage admins to enable challenges, maybe even make it by default on.
1) Do not end AuthVerifierPipeline processing upon receiving a challenge response from an AuthVerifier. Instead, proceed to the next AuthVerifier, and if all are unsuccessful, then proceed with fulfilling the request with the guest user.
2) If request fulfilment results in a PrincipalException and the user is not the guest user, then send all the challenges together in a single www-authenticate header. The user-agent will then pick the most secure auth scheme offered in the challenge and make another request with credentials.
The AuthVerifier processing order should be admin configurable.
Some benefits of this proposal:
- An integrator will not need to know upfront what auth schemes are supported and required by a particular URL. Making integrations easier.
- Separation of concern between how to authenticate a user (a portal concern), and when to authenticate a user (a plugin / service concern)