SplittingClaims

Current File(s): conf/attribute-resolver.xml, conf/attribute-filter.xml

Overview

Claims are released as part of id token or as part of userinfo response. The basic filtering and attribute resolving examples show how a filtered claim ends up always in both (assuming userinfo endpoint is deployed at all). In some cases it is desirable to release a claim in one or the other, id token or in userinfo response, but not in both. This is called splitting claims.

Splitting and attribute resolver by example

The splitting basically happens already in attribute definition phase. Assuming you have a attribute name for claim "name" already defined

<!-- standard claim name fetched from static connector -->
<AttributeDefinition id="name" xsi:type="Simple" sourceAttributeID="name">
    <Dependency ref="staticAttributes" />
    <AttributeEncoder xsi:type="oidcext:OIDCString" name="name" />
</AttributeDefinition>  

which you may release already for scope "profile" in your attribute filter. If you need a another filtering rule releasing claim "name" for instance by a request but only in userinfo response you need to define a second attribute, name_ui that holds the same value but a encoder that activates only for userinfo responses.

<!-- claim that may be encoded only for userinfo response -->
<AttributeDefinition id="name_ui" xsi:type="Simple">
    <Dependency ref="name" />
    <AttributeEncoder xsi:type="oidcext:OIDCString" activationConditionRef="UserInfoPredicate"
        name="name" />
</AttributeDefinition>

Now you may refer to that attribute definition in attribute filter.

Splitting and attribute filter by example

<AttributeFilterPolicy id="SPLITTING_CLAIMS">
    <PolicyRequirementRule xsi:type="ANY" />
    <!-- Release name in userinfo if specifically asked to be released for userinfo -->
    <AttributeRule attributeID="name_ui">
        <PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" matchOnlyUserInfo="true" />
    </AttributeRule>
</AttributeFilterPolicy>

Outcome

The released claim will end up only to userinfo response, not to a id token. The consent, if configured, is however asked also for this claim in the authorization endpoint, even though it may not be released at that phase.

As you may end up like in this example having different attribute definitions having encoder named the same i.e. "name" in this case, it is important that they hold also the same value as in example - otherwise it really would not make any sense. In the case of overlapping filtering rules releasing different attributes having samely named encoders - attributes name and name_ui in this example case - which is expected, the value(s) of only one attribute having encoder named "name" will end up in the response.

Beans

• UserInfoPredicate, attribute resolver specific bean for activating encoder only for userinfo responses.
• IDTokenPredicate, attribute resolver specific bean for activating encoder for setting the claim only to id token.