Attributes with the type SubjectDerivedAttribute not passed to id_token or userinfo

[psagne]

We have some attributes which are passed from the authentication phase and retrieved using the SubjectDerivedAttribute definition.

It works without any problem using SAML. They are also resolved at the "authorize" step.
But the values are not resolved at the token or userinfo steps. There is just 0 values.

An example of the definitions we use :

    <AttributeDefinition id="email" xsi:type="SubjectDerivedAttribute" principalAttributeName="mail">
        <AttributeEncoder xsi:type="oidcext:OIDCString" name="email"  placeToIDToken="true" denyUserinfo="false"/>
    </AttributeDefinition>

[psagne]

After reading the doc a little better, i added setToToken="true" to the AttributeEncoder, like this :

<AttributeDefinition id="email" xsi:type="SubjectDerivedAttribute" principalAttributeName="mail">
    <AttributeEncoder xsi:type="oidcext:OIDCString" name="email"  placeToIDToken="true" denyUserinfo="false" setToToken="true"/>
</AttributeDefinition>

In the DEBUG log, i see that the value is encoded into the authorization code, but not in the access token, so it is still not returned by the userinfo endpoint.

[psagne]

With a little more digging :

• the attributes defined this way are encoded inside the authz code in the "dl_claims_ui" and "dl_claims_id" fields but the "dl_claims" field is empty
• the attributes are present inside the id_token
• inside the access token, the "dl_claims_ui" and "dl_claims" fields are both empty
• as a result, the userinfo endpoint returns none of these attributes.
  It seems like the generation of the access token tries only to get values from the attribute resolver without taking care of the "dl_claims_ui" values encoded inside the authz code
  Precision : I am using the v1.1.0 of the extension with Shibboleth IdP 3.4.6

[psagne]

With the implicit flow, it works as advised : the attributes defined with setToToken are properly encoded inside the token and returned by userinfo. So I really think the problem really is passing the values from the code to the token in the "authorization code" flow.

[hjmikkon]

Finally got this replicated and resolved. Thank you very much for the analysis: in short it was all about token-endpoint ignoring the dl_claims_ui claims encoded in the authorization code.

The fix will be released in v1.1.1 and also for IDP4-compatible 2.0.0.