NOTE: This is a ticket that the Spring Security team is reviewing for inclusion. It's not considered ready to implement yet. When it is, this disclaimer will be removed and the title may change
During the work for #2603, it was discussed that when using .x509 and .formLogin together:
http
.x509(Customizer.withDefaults())
.formLogin(Customizer.withDefaults())
// ...
Then when the user is unauthenticated, it redirects to /login.
This makes sense since, without MFA, this HttpSecurity statement reads: either X.509 or Form Login is a permissible way of authenticating.
However, if MFA is activated, then it may not make sense to redirect to /login. This is because X.509 certificates are a pre-authentication mechanism. So, if we are redirecting to /login, this means that we already know that there was no X.509 certificate and the second factor (X.509) will ultimately fail.
This is addressed when the user is already logged in by way of the MissingAuthorityDelegatingAccessDeniedHandler, which can prioritize X.509's authentication entry point (Http403AuthenticationEntryPoint) based on the order in which the entry points are declared.
However, before authentication, the filter chain doesn't have access to any such information.
It would be nice if, when MFA is activated and X.509 is listed as one of the required factors, that unauthenticated users are also forbidden if the X.509 filter doesn't find a certificate.
We may be able to have GlobalMultifactorAuthenticationConfiguration publish a bean that X509Configurer or ExceptionHandlingConfigurer is aware of. This would allow either the X509AuthenticationFilter or the ExceptionHandlingConfigurer to modify their configuration.
Comment From: therepanic
Hi, @jzheaux! Can I work on it?
Comment From: jzheaux
Hi, @therepanic, and thanks for your interest!
This is an idea still under discussion, so we aren't quite ready yet for a contribution on this one. I've added a disclaimer to clarify this.