How to use KeycloakAUthRequestPostProcessor in 2.4.1? about spring-addons HOT 7 CLOSED

Changing it to this makes it compile again:

        return new KeycloakAuthRequestPostProcessor(Optional.of(new SimpleAuthorityMapper()))
                .authorities("user", role)
                .accessToken(accessToken -> {
                    accessToken.setPreferredUsername(email);
                    accessToken.setSubject(authServerUserId);
                    accessToken.setGivenName(givenName);
                    accessToken.setFamilyName(familyName);
                })
                .idToken(idToken -> {
                    idToken.setPreferredUsername(email);
                    idToken.setSubject(authServerUserId);
                    idToken.setGivenName(givenName);
                    idToken.setFamilyName(familyName);
                });

But now my @AuthenticationPrincipal is null in my controller methods. The reason seems to be that instead of a KeycloakAuthenticationToken, a KeycloakPrincipal should be used as the type now. Any idea why this is? And is there a way to use the KeycloakAuthenticationToken?

I use the KeycloakAuthenticationToken because I do token.getAccount().getRoles() at a certain point to retrieve the current user roles.

from spring-addons.

The issue with the null principal is due to spring-projects/spring-framework#26380 If you can confirm that my changes for KeycloakAuthRequestPostProcessor are what they should be then this issue can be closed.

from spring-addons.

Hi @wimdeblauwe , as you found out, version 2.3.0 introduced breaking changes in claims declaration.
Sorry for migration effort :/

The motivation was to get closer to OpenID specs.
The motivation for this motivation is to reuse some code from my OpenID Authorization implementation and as so maintain less code.

As you noted, prior to 2.3.0, using .name(email) was setting preferredUsername which was a rather bad idea.
I understand the name from javax.security.Principal as a way to define identity, which is subject in OpenID world.

KeycloakAuthRequestPostProcessor::name was just a shortcut and changing its behavior to set subject instead of preferedUsername (which is a Keycloak private claim) was too confusing IMO. So I just dropped it.

P.S.
keycloak AccessToken extends IDToken, so if you externalize idToken consumer function, you could use it from accessToken one (and avoid the code duplication in your last sample).

from spring-addons.

Ok, thank you for the quick reply. So my changed code is correct?

from spring-addons.

It seems good. Doesn't it work as expected ?

from spring-addons.

from spring-addons.

Ok, nice.

from spring-addons.