OPAttributeFiltering
Overview
OIDC claims are of course subject to identical behavior with regard to the AttributeFilterConfiguration since filtering operates on the internal IdPAttribute objects prior to encoding into claims. There are however a couple of additional extensions supported that are specific to OIDC use cases and policy needs.
There is an example file supplied, conf/examples/oidc-attribute-filter.xml, with examples that may be helpful in adding to your own policies.
Configuration
Because these are extensions, their xsi:type definitions live in a separate XML namespace and schema (unfortunately an unavoidable callback to the days when multiple namespaces were required in configurations).
Namespace: urn:mace:shibboleth:2.0:afp:oidc
Schema: http://shibboleth.net/schema/oidc/shibboleth-afp-oidc.xsd
In order to use any of these extension types, the root element of the filter configuration file needs to be adjusted to declare a namespace prefix for the extension namespace and add in the schema location to address some fundamental XML bugs in Spring:
<AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns="urn:mace:shibboleth:2.0:afp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:oidc="urn:mace:shibboleth:2.0:afp:oidc"
xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd
urn:mace:shibboleth:2.0:afp:oidc http://shibboleth.net/schema/oidc/shibboleth-afp-oidc.xsd">OIDCScope Policy Rule
One additional policy rule is provided, with xsi:type="oidc:OIDCScope", which returns true if and only if any of the scope values in the OIDC authentication request matches a supplied string. By default, the scope requested must be a scope registered in the client's metadata. This can also be customised, see https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3001352203 .
It supports the following XML Attributes:
Name | Req? | Type | Description |
|---|---|---|---|
value | Y | String | The OAuth scope for which the policy applies |
Example
This example releases two mail-related claims to clients that are authorized to, and request, the "email" scope.
<AttributeFilterPolicy id="OPENID_SCOPE_EMAIL">
<PolicyRequirementRule xsi:type="oidc:OIDCScope" value="email" />
<AttributeRule attributeID="mail">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>
<AttributeRule attributeID="email_verified">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>
</AttributeFilterPolicy>AttributeInOIDCRequestedClaims Matcher
One additional matcher is provided, with xsi:type="oidc:AttributeInOIDCRequestedClaims", which operates by comparing an IdPAttribute's values against the requested claims parameter of an OIDC authentication request. The default functionality filters out all attribute values that do not have a matching claim in the id token or userinfo sections of requested claims.
The translation between the requested claim name and the IdPAttribute id is based on the transcoding rule(s) that are configured, including automatically reversed rules constructed based on any <AttributeEncoder> elements (this is how SAML mappings are constructed as well).
It supports the following optional XML Attributes:
Name | Type | Default | Description |
|---|---|---|---|
matchIfRequestedClaimsSilent | Boolean | false | Releases values if the request did not specify any requested claims at all |
matchOnlyUserInfo | Boolean | false | Releases values only if the claim is requested for the UserInfo token |
matchOnlyIDToken | Boolean | false | Releases values only if the claim is requested for the ID token |
onlyIfEssential | Boolean | false | Releases values only if the claim is requested as "essential" |
Example
The example shows how to set up rules to release attributes specifically for clients that request them in various ways.
<AttributeFilterPolicy id="REQUESTED_CLAIMS">
<PolicyRequirementRule xsi:type="ANY" />
<!-- Release picture if asked. -->
<AttributeRule attributeID="picture">
<PermitValueRule xsi:type="oidc:AttributeInOIDCRequestedClaims" />
</AttributeRule>
<!-- Release email in ID token if specifically asked for in ID token. -->
<AttributeRule attributeID="mail">
<PermitValueRule xsi:type="oidc:AttributeInOIDCRequestedClaims" matchOnlyIDToken="true" />
</AttributeRule>
<!-- Release phone_number in UserInfo token if specifically asked for in UserInfo token. -->
<AttributeRule attributeID="telephoneNumber">
<PermitValueRule xsi:type="oidc:AttributeInOIDCRequestedClaims" matchOnlyUserInfo="true" />
</AttributeRule>
<!-- Release name if specifically asked for in UserInfo token and flagged as essential. -->
<AttributeRule attributeID="displayName">
<PermitValueRule xsi:type="oidc:AttributeInOIDCRequestedClaims" matchOnlyUserInfo="true"
onlyIfEssential="true" />
</AttributeRule>
</AttributeFilterPolicy>