In OIDC Authorization flow, user email is not returned.

Products

• SITEMINDER

Issue/Introduction

Customer implements OIDC Authorization flow (not implicit flow), siteminder is Authorization provider, client is custom code.
After user authentication, customer was able to get id_token and the access_token.
However, when in next step,  using access_token to get the userinfo from the following url https://example.example.com/affwebservices/CASSO/oidc/userinfo,
the response is only within scope of "openid".

There is a second scope configured in siteminder called "profile", but the "profile" scope was not checked and data was not fetched.

"openid" scope only contains user DN.
"profile" scope contains user email.
user email is what the application needs.

Environment

Release : 12.8

Component : SITEMINDER SECURE PROXY SERVER

Cause

There could be many reasons:

1. Custom code could have logic problem, where REST calls or sequence of calls were not properly made.

2. OIDC Authorization flow is different from implicit flow, in that OIDC Authorization flow is a two stage process. User must submit access_token to userinfo endpoint in order to get the user information in second step.

3. OIDC Authorization flow by default uses scope named "openid", unless other scope is properly configured, and client code is requesting all scopes during authentication.

4. OIDC client configuration in siteminder must enable "Send User Information in ID Token". Verify all client side endpoints configuration.

5. Check Authorization provider configuration on Claims mapping, Scope Mapping.

FWStrace Log analysis shows mismatch between what is configured vs. what is requested vs. what is actually allowed and processed.

What is configured:

[01/05/2021][10:30:22][22587][139658086188800][1e7e62a4-f82eee1e-499fba20-d575c1c6-12cd3db8-2c1][OpenIDConnectTunnelClient.java][getOidcClientInfo][client Info: {redirectURI=[https://xxxxxxxxxxxxxx.com/sso/authcode/callback, url://auth/], responseTypes=[Code], applicationType=PUBLIC, clientID=.................................acrConfiguration={}, signUserInfo=false, signingAlgorithm=RS256, authorizationCodeExpiryTime=300, authenticationURL=https://xxxxxxxxxxxxxx.com/affwebservices/secure/secureredirect, authenticationType=1, IDTokenExpiryTime=1800, scopeAndClaimsMapping={openid=uid, profile =email}}, clientAuthentication=CLIENT_SECRET_BASIC, scopes=[openid, profile], Realm=CA.SM::Realm@06-000280da-0c91-1f97-90da-53fe0a310000]

What is requested:

[01/05/2021][11:02:42][22587][139657698318080][189f7a74-19a97d8f-e0d2fed9-042bbda1-e34b42e9-97c][AuthorizationService.java][validateInputWithConfiguration][state=kaY6zyewoGqQ8cnF47ied5MUHjj7i87hp2qRpXp8hzoWYElscJOajqHuoZp9ppCdDOf2V6HsmINZOa69HzGihgeBi5vj4jOUPdvPQwq5fUvVuO5xNn3jDOYAzzlt9CWb]
[01/05/2021][11:02:42][22587][139657698318080][189f7a74-19a97d8f-e0d2fed9-042bbda1-e34b42e9-97c][AuthorizationService.java][validateInputWithConfiguration][scope=openid profile]

What is actually allowed and processed:

[01/05/2021][11:02:42][22587][139657698318080][189f7a74-19a97d8f-e0d2fed9-042bbda1-e34b42e9-97c][AuthorizationService.java][validateInputWithConfiguration][validScopes: openid]

For some reason, policy server only recognizes one scope, not any other.

Resolution

In the end, customer created the new authorization provider and changed corresponding settings under the client and that fixed the issue.

One should note that any federation object changes could result to service recycle to ensure no stale cache is interfering testing.

Customer could also try rename scope "profile" to default name "openid", the config result is that there is only one scope mapping called "openid". And its claim names are: email,uid,lastname,firstname

As consequence, client requests has to change to match that as well on scope.

Even though claim names are separated with comma, the scopes request has no comma, only white space.