Expected Behavior
AbstractPreAuthenticatedProcessingFilter should provide template method or something similar for token creation. Template method can have current behaviour as default implementation to ensure backwards compatibility.
for example:
final AbstractAuthenticationToken authRequest= createAuthenticationRequest(principal, credentials)
Current Behavior
Currently private void doAuthenticate() is hardcoded to create one type of authentication token: PreAuthenticatedAuthenticationToken authRequest = new PreAuthenticatedAuthenticationToken(
principal, credentials);
Context
User can be pre-authenticated in many ways. Custom internal token, kerberos...etc all of these token have in common that they are pre-authenticated and should be passed to the correct authentication provider and UserDetailsService. Currently AbstractPreAuthenticatedProcessingFilter only produces one type of token which will be handled by PreAuthenticatedAuthenticationProvider. If the server has to support multiple pre-Authenticated tokens at the same time each one should have their own token so that they can be passed to the correct PreAuthenticatedAuthenticationProvider.
Are you aware of any workarounds? - To create custom filters from scratch as AbstractPreAuthenticatedProcessingFilter is not subclass friendly when it comes to token creations. or - Perform logic in UserDetailService that should belong in AuthenticationProvider
Comment From: rwinch
Thank you for reaching out. It sounds like you really don't want to use the defaults. This is fine, but Spring Security is never going to meet all of your needs. My suggestion is for you to implement your own Filter and then set the SecurityContextHolder directly. This gives you complete freedom.
Comment From: jukkaleh
@rwinch
This issue was about creating my own filter and having to copy-paste spring source code into it unnecessarily. I wanted do it via inheritance (subclassing), but couldn't because one method doAuthenticate would only create one type of authentication token. Spring security supports multiple authentication tokens why this filter which is supposed to be subclassed cannot have template method for token creation. Logic would remain the exactly the same and be backwards compatible?