Expected Behavior
OpenSaml4AuthenticationProvider should be extendable.
Current Behavior
OpenSaml4AuthenticationProvider is final. Alternatively it should be possible to use a custom UserDetailsService or have some mechanism to run additional logic or customize the returned user principal.
Context
I was wondering why the provider class is final and cannot be extended. Maybe my use case is not valid or there is a better way to do this but as far as I can see we should be able to extend the behaviour.
We have several providers in our application and our approach is to let the base providers handle their thing in the authenticate() method and then after authentication via the provider we run some application specific authentication logic and maybe sync the local user fields from the ones we get from a provider in the derived class. As the last step we map whatever we have in the provider specific principal to our own principal and return that. That way we have different authentication methods but always the same principal object in the end. In the old saml2 library from spring extension (which is now depricated) It was possible to supply your own UserDetailsService.
When I look at the examples in the official documentation getting the principal looks something like this:
@RequestMapping("/secured/hello")
public String hello(@AuthenticationPrincipal Saml2AuthenticatedPrincipal principal) {
....
}
which seems to couple this endpoint hard with the used authentication method. If a user were to log in via one of the other providers this endpoint would not work. Maybe I don't understand something correctly here but shouldn't the application itself be agnositc of what method was used, as long as the user principal has the correct authorities/fields. And isn't this what the UserDetailsService is for?
Comment From: tom-mayer
Found setResponseAuthenticationConverter which can be used to overwrite the behaviour, sorry.