New configuration to obtain the User/Group Information from the additional Access Token and Userinfo

[felix-liang]

Feature: OpenLiberty/open-liberty#25460

Relevant docs page: https://openliberty.io/docs/latest/reference/feature/openidConnectClient-1.0.html

New configuration: tokensOrderToFetchCallerClaims

With the current logic, the User or Group information can only be obtained from ID Token. However, in some clients' environment, they can not have group information as part of the ID Token, instead Access Token. In order to align with Jarkata EE Security implementation, the new feature will also look up the Userinfo as well.

The following are the configuration options,

• IDToken
  This is the default value. If the configuration is not specified, the "IDToken" will be used.
• AccessToken IDToken Userinfo
  With this option, if a claim is not found from Access Token, it will keep searching in IDToken and finally Userinfo.

Below is one example of configuring the parameter.

<openidConnectClient tokensOrderToFetchCallerClaims="AccessToken IDToken Userinfo"  userIdentifier="unique_name" groupIdentifier="roleid" ... />

In the above example, when looking up a user's group, if claim "roleid" doesn't exist in AccessToken, it will continue searching in IDToken, if still not found, then it will check Userinfo, in the end if it still can not find it, then the user won't have any group information it belongs to.

However, when checking the user identifier claim, if it doesn't find it from all the configured tokens, it will respond unauthorized response code.

[dmuelle]

Hi @felix-liang - will OpenLiberty/open-liberty#25460 be included in 23.0.0.12 or a later release?

[felix-liang]

Yes, It will be included in 23.0.0.12.

[dmuelle]

Hi @felix-liang - I have a few questions to clarify

1. what are the possible combinations of values for this attribute? Is it any combination of AccessToken IDToken Userinfo? I understand IDToken is the default. But what if someone just specifies
   tokensOrderToFetchCallerClaims="Userinfo"? Is that valid? Or tokensOrderToFetchCallerClaims="IDToken AccessToken Userinfo"?

Or are the only choices the default or tokensOrderToFetchCallerClaims="AccessToken IDToken Userinfo" ? I see as above you listed only two config options, but if that is the case, then why isn't the attribute boolean t/f?

2. What kind of entity is Userinfo? is it an application class or method? an endpoint?

Thanks!

[felix-liang]

Hi @dmuelle, below is my comments

1. there are only two options, IDToken, or IDToken AccessToken Userinfo. The Userinfo alone is not valid.
   This is to align the same implementation in Jarkata EE Security. I understood this is a bit confusing, but that was the decision from the team. The intention was to not allow the developer to use different combianations. However, I do agree that there is possibly a better value for IDToken AccessToken Userinfo option.

2. Userinfo is part of the OpenID Connection, there is a specific service call to OIDC Provider(OP) to get the details of user information, the response is in the format of JSON Web Tokens. That could be used for authenticating/authorizing the user.

Hope that helps a bit.

[dmuelle]

Thanks Felix, a draft of the update is now available for review:

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/reference/feature/openidConnectClient-1.0.html#access-token

When you have chance, let me know if any further edits are needed. If not, you can add the technical reviewed label to this issue and the update will publish with 23.0.0.12.

[felix-liang]

Just one thing I'd like to point out is that the tokensOrderToFetchCallerClaims look-up rule applies to the userIdentifier as well. This is a way to find out the user name from the tokens.

[dmuelle]

Hi Felix, here's the updated draft to clarify that the rule looks for both userIdentifier and groupIdentifier values.

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/reference/feature/openidConnectClient-1.0.html#access-token

let me know if any further edits are needed. Thanks!

[felix-liang]

Thanks David! It looks good to me.
However, not sure if it's permission issue or not, I couldn't find where I can add a new label to this issue.

[dmuelle]

No worries- I'll add it. Thanks Felix!

[dmuelle]

@ramkumar-k-9286 this update is ready for peer review when you have a chance