0
votes

Consider the case in which you have WSO2 IS (5.3.0) and an upstream IDP (e.g. a SAML IDP).

Login procedure is as follows: User accesses a service provider (e.g. OpenID Connect client) which redirects to the local WSO2 IS. The SP is configured to use the upstream SAML IDP or local login as outbound authentication option. The upstream SAML IDP returns some attributes in the assertion but no JiT provisioning is configured.

Now use the access token the service provider gets from the login process to

  1. query the SOAP token validation endpoint of WSO2 IS with the token -> User claims returned are the claims from the local user store (embedded LDAP)
  2. query the userinfo REST endpoint -> User claims are the claims that were returned by the upstream IDP in the SAML assertion, userinfo does not return any local attributes

Is this a configuration issue? Is there a way to work around this behavior?

What makes things even worse with the userinfo endpoint is that the claims returned depend whether the user logs in via a local login (in WSO2 IS) or via the upstream external IDP. That is not the case with the SOAP token validation endpoint which returns the same attributes in both cases.

1
what is the IS version you are using?farasath
Added this to the post now. It is Identity Server 5.3.0Hos

1 Answers

0
votes

I have made more investigation on this. It looks like the SOAP token validation endpoint uses the claim retriever which directly accesses the user store (e.g. LDAP) whereas the userinfo endpoint gets the profile attributes from a cache. The cache entry is generated during authentication time and populated with infos from the SAML assertion.

A workaround might be to enable JiT provisioning for the IDP. Unfortunately there is still a mismatch as long as no account association is maintained in IDN_ASSOCIATED_ID.

IMO the account association should be automatically created in case a user is jit provisioned. Not sure whether this is a bug or per design. At least there are options to work around this.