Provide a way to append extra request matchers to the default matcher for AbstractPreAuthenticatedProcessingFilter

[crizzis]

Expected Behavior

It should be possible to add extra matching behavior to the default AbstractPreAuthenticatedProcessingFilter$$AbstractPreAuthenticatedProcessingFilter

Current Behavior

While it is possible to overwrite the matcher using AbstractPreAuthenticatedProcessingFilter#setRequiresAuthenticationRequestMatcher, there is no way to combine the logic of the new matcher with the default one (e.g. using new AndMatcher(defaultMatcher, customMatcher)), bc there is no getter for requiresAuthenticationRequestMatcher

Context

There are no simple workarounds, bc the default AbstractPreAuthenticatedProcessingFilter$$AbstractPreAuthenticatedProcessingFilter uses private fields from the outer class, so it cannot be easily reimplemented.

I imagine this could be simply an overlook, bc in contrast to AbstractAuthenticationProcessingFilter which is the base class for most other authentication filters, there is no protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) method that one could override.

If an analogous a method was present in AbstractPreAuthenticatedProcessingFilter as well, we could simply override it with return super.requiresAuthentication(...) && <insert custom logic here>, without the need of exposing the default matcher.

[jzheaux]

I think instead we should reimagine the default itself. With a simpler default, we may be able to make it public so that it can be more easily used with AndRequestMatcher.

Could you please describe the custom logic you need to add? That may help to ensure we are making the enhancement in the most productive place.

[crizzis]

Nothing fancy, I'm just trying to combine it with an AntPath matcher17 wrz 2024 02:38 Josh Cummings @.***> napisał(a): I think instead we should reimagine the default itself. With a simpler default, we may be able to make it public so that it can be more easily used with AndRequestMatcher. Could you please describe the custom logic you need to add? That may help to ensure we are making the enhancement in the most productive place.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[jzheaux]

One approach that I like is to implement AuthenticationConverter (say X509AuthenticationConverter) -- it would perform the logic of AbstractPreAuthenticatedProcessingFilter's default request matcher and construct the appropriate Authentication instance. (You can see ServerX509AuthenticationConverter for the reactive version of what I'm talking about.)

Having done this, then you can use the general-purpose AuthenticationFilter instead by setting its request matcher:

X590AuthenticationConverter authenticationConverter = new X509AuthenticationConverter();
AuthenticationManager authenticationManager = new ProviderManager(new PreAuthenticatedAuthenticationProvider());
AuthenticationFilter authenticationFilter = new AuthenticationFilter(authenticationConverter, authenticationManager);
authenticationFilter.setRequestMatcher(yourAntMatcher);

I failed to ask you what your pre-authentication scenario is; it might not be X.509. Could you elaborate on that and we can come up with the right AuthenticationConverter implementation together?