IBM Verify

Hi, my goal is to have a jwt claim containing the user's groups (i'm talking about an oauth2.0 flow).

Right now i'm able to do it in the oauth "authorization_code" flow, since the user login on webseal i'm able to retrieve its groups with:

stsuu.getGroups()

This method only works if the users has passed through webseal and it's session is fully populated by the policy server.

I'd like to be able to retrieve the groups even if the user doesn't login through webseal (for example during a refresh_token flow or any other case).

What is the best way to achieve this? I have an idea:

Retrieve the groups inside the mapping rule via a REST call to the ISVA api and caling the pdadmin (user show-groups), i could use the "com.ibm.security.access.httpclient.HttpClient" class to perform the rest call and then parse the response json to get the groups array.

Am i going too far? There is a better and simpler way to populate a jwt with the user's groups?

Thank you,

Sacha 

Use the UserLookupHelper utility class to retrieve the groups. Do not call ISVA LMI APIs, including those for pdadmin, from any kind of runtime flow.

stsuu.getGroups()

Hi Sacha,

From this link: https://www.ibm.com/docs/en/sva/9.0.7?topic=support-oidc-claims-customization

Saving Values or Parameters

Security Access Manager enables you to save values or parameters that are related to the claims at the /authorize endpoint.

For example, some request parameters can be specified at the /authorize endpoint, but the claims might be produced at the /token or /userinfo endpoint. The claims need to be saved so that they can be available at the /token or /userinfo endpoint. An example of this is the claims_locales request parameter.

Another example is the existence of values, such as credential information, that are available at the /authorize endpoint, but need to be output at the /token or /userinfo endpoint. An example of this is the values that are used in the credential type attribute sources. You can save these values. This overcomes the limitation of the attribute source such that for the credential-type attribute source, the context exists only at the /authorize endpoint, and if the values are not saved, the context is not available at any other endpoint.

You can do this by creating a context attribute in the STSUU of the type urn:ibm:names:ITFIM:oidc:claim:parameter for parameter or urn:ibm:names:ITFIM:oidc:claim:value for value.

The difference between these two types is that, during runtime, the claim value is put back into STSUU Attribute List under type urn:ibm:names:ITFIM:5.1:accessmanager, but the claim parameter is put in the STSUU context under type urn:ibm:names:ITFIM:oidc:claim:parameter.

Note that these saved values or parameters exist as long as the grant exists. When the grant is removed or expires, the saved values and parameters are removed.

For example, we man modify the pre-token mapping rule and add the following code to save the AZN_CRED_PRINCIPAL_NAME attribute.

var saveValue = stsuu.getAttributeContainer()
         .getAttributeValueByNameAndType("AZN_CRED_PRINCIPAL_NAME", 
         "urn:ibm:names:ITFIM:5.1:accessmanager");
if (saveValue != null) {
	var attro = new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("AZN_CRED_PRINCIPAL_NAME",
		"urn:ibm:names:ITFIM:oidc:claim:value", saveValue);
	stsuu.getContextAttributes().setAttribute(attro);
}

By doing this, the CredentialNickName attribute source (as shown in the example earlier in this article) can be resolved in the /token or /userinfo endpoint.

stsuu.getGroups()