Summary

Using with PreAuthenticatedGrantedAuthoritiesUserDetailsService there is a problem since "user details service" expects GrantedAuthoritiesContainer from the details attribute of the PreAuthenticatedAuthenticationToken (even when the token itself has a field holding a collection of GrantedAuthorities and implements both Authentication and CredentialsContainer interfaces).

The problem gets worse in combination with RequestHeaderAuthenticationFilter since it only attends to authentication header, and uses WebAuthenticationDetails which does not attend to any additional header.

I think i would be easy and convinient to provide a preauthenticated system supporting basic authorization out of the box.

This could be achieved easily both providing an extended RequestHeaderAuthenticationFilter, or an extended WebAuthenticationDetailsSource.

In the other hand i think UserDetailsService should not expect GrantedAuthoritiesContainer in the details but use the Collection present in the token.

Does this makes sense?

Actual Behavior

Cannot use preauthenticated scenario with authorization in the request header unless providing additional custom classes.

Expected Behavior

Simple authorization working out of the box with a standard header as the authentication does.

Comment From: rwinch

It sounds as though you are looking for Spring Security to add support for an AuthenticationDetailsSource that can create a PreAuthenticatedGrantedAuthoritiesWebAuthenticationDetails from the headers. Does that sound correct?

Most of the RequestHeaderAuthenticationFilter scenarios I have seen need to provide a UserDetailsByNameServiceWrapper instance which looks up the authorities externally. What specific technology are you using that is injecting the roles into the headers?

Comment From: rblazquez

It sounds as though you are looking for Spring Security to add support for an AuthenticationDetailsSource that can create a PreAuthenticatedGrantedAuthoritiesWebAuthenticationDetails from the headers. Does that sound correct?

Exactly!

Most of the RequestHeaderAuthenticationFilter scenarios I have seen need to provide a UserDetailsByNameServiceWrapper instance which looks up the authorities externally. What specific technology are you using that is injecting the roles into the headers?

In my specific case i am implementing API-GW pattern on a microservices cluster. I want to delegate authentication in API-GW component so it will inject both principal and authorities as request headers and the rest of the components (not exposed) just consume them with no extra requests. (This makes sense to me but i am open to opinions).

Anyway I found that RequestHeaderAuthenticationFilter plus all the preauth classes, fits perfect for this scenario just missing this very simple "RequestHeaderWebAuthenticationDetails" or something like that considering an additional header for the authorities the same as RequestHeaderAuthenticationFilter does with principal.

Of course it is very easy to extend WebAuthenticationDetailsSource to do so, but i find weird to include authorities handling in PreAuthenticatedGrantedAuthoritiesUserDetailsService when there isn't any default mechanism available to place those authorities there ... so i decided to place question here to confirm i am not missing any point.

Also, beyond any specific technology, i though that it would be nice, for the sake of completeness, that spring-security includes a default mechanism for authorization in a preauthentication scenario, but this is just my perception and, of course, i can be wrong.

Finally I question myself why the framework assumes i will rely on an additional external system, different from the one that is in charge of authentication, in order to set the Roles.

@

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: blacar

Sounds fair.

El mar, 15 dic 2020 a las 16:18, Spring Issues (notifications@github.com) escribió:

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-security/issues/4359#issuecomment-745398503, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7H4CZBICMIYSJU5CN2MBLSU6D5LANCNFSM4DNJA56Q .

Comment From: jzheaux

Pardon our dust here, @blacar, as we do some issue cleanup. You had already provided feedback earlier, and I don't think your ticket has been fully addressed, yet, so let's keep the issue open.