Which is the role of "username-claim: preferred_username" ?

[rgambelli]

Hi,

I would like to know the specific role of the property:

com:
  c4-soft:
    springaddons:
      oidc:
        ops:
        - iss: https://oidc.c4-soft.com/auth/realms/master
          username-claim: preferred_username

In the code tutorial hosted on baledung I don't find it, here is the bff application.yml but I'm pretty sure that some times ago there was, in my code there is and I was inspired by the tutorial.

Maybe it's a concept related only to applications acting as resource-server ?
What if bff is either a client or a resource-server like in my scenario, do I need it?

I saw that if the value is $.preferred_username (with starting dollar) then I receive this error:
o.s.s.w.s.a.AuthenticationWebFilter : Authentication failed: [invalid_user_info_response] An error occurred reading the UserInfo response: Missing attribute '$.preferred_username' in attributes (lambda$authenticate$8 AuthenticationWebFilter.java 128)

while if the value is preferred_username then the flow is ok.

Thanks as always for the explanation, bye

[ch4mpy]

$.preferred_username is a JSON-path to a claim at the root of the JSON payload.

preferred_username is a String that JSON-path can bind to the same thing as $.preferred_username.

spring-addons-starter-oidc uses JSON path to resolve the username in JSON payloads (JWT content or introspection response) but spring-security doesn't. As a consequence:

• com.c4-soft.springaddons.oidc.ops[x].username-claim can start with $. (it has to if the target claim is a nested claim)
• spring.security.oauth2.client.provider.my-provider.user-name-attribute must not start with $. but can target only claims at the root of the payload (not nested ones)

What I did lately in apps being both a client with oauth2Login and a resource server where I want to change the claim used to set the Authentication#name with a claim at the root of the JSON payload, is ensuring that spring.security.oauth2.client.provider.my-provider.user-name-attribute (which is used in clients with oauth2Login) and com.c4-soft.springaddons.oidc.ops[x].username-claim (which is used on resource servers) have the same value by either setting one with the other or by using a short-end to set both.

Authentication is a Spring interface which answers two questions:

• who is the user?
• what are his authorities?

When building a security context for a request, we need to provide both. For OAuth2, Spring uses as default:

• sub claim value as name. You may change that with any unique & non-nullable value, but this default is actually a good choice in many cases.
• scope claim value as source for authorities, adding a SCOPE_ prefix. As Role Based Access Control is part of neither OAuth2 nor OpenID standards, Spring had to pick something but we should almost always override this default (and I believe that using an empty list as default would have helped beginners to understand that scopes are not roles...)

The Authentication instance and how it is built depends on the configuration:

• on a client with oauth2Login, we get an OAuth2AuthenticationToken whose principal is an OAuth2User (specialized into an OidcUser in the case of an OpenID authorization server, case in which the OAuth2AuthenticationToken is built from the ID-token instead of the userinfo response). We have no simple way to change the type of the built Authentication in this case and only little latitude on what it is populated with (just the name with spring.security.oauth2.client.provider.my-provider.user-name-attribute and authorities with a GrantedAuthoritiesMapper or OAuth2UserService)
• on a resource server with JWT decoder, we get a JwtAuthenticationToken by default, but we have a complete control on the Authentication type and on its content by configuring the jwtAuthenticationConverter(jwt -> ? extends AbstractOAuth2AuthenticationToken)
• on a resource server with access token introspection, we get a BearerTokenAuthentication by default, but as for the JWTs, we can change that we have a complete control on its content by exposing an OpaqueTokenAuthenticationConverter bean