Overview
OIDC deals in "claims" instead of "attributes" but the concept is the same and the AttributeResolverConfiguration and (optionally) AttributeRegistryConfiguration are used as with SAML and CAS to pull in the appropriate data and encode it into JSON in responses.
The only special consideration for OIDC is the specialized encoding requirements, which are handled (as in SAML) either via "inline" AttributeEncoders, or by defining "transcoding" rules that map between IdPAttributes and JSON-encoded claims.
An example file, conf/examples/oidc-attribute-resolver.xml, is included that contains some examples of custom encoders, definitions that match the optional "default" claim rules, and suggested starting points for producing the "sub" claim (see also OPSubClaim).
Timing of Resolution
The Authorize, Token and Userinfo profile endpoints all trigger attribute resolution and filtering phases. The motivation for this is to maintain an implementation that is as stateless as possible to avoid complex clustering technologies. Each endpoint is able to resolve attributes independently and therefore attribute information need not be stored to server side. This also ensures up to date values for claims returned when an access token is refreshed for extended period of time.
(For long time Shibboleth deployers, this is somewhat analagous to the old days when SAML attribute queries were common.)
There are a few obvious downsides to this stateless approach. One is that, depending on the OIDC response type, the same attribute may be resolved more than once. This is particularly an issue if the resolution process is costly and the intention is only to authenticate the user. The ResultCache feature is helpful for this case.
A harder problem is when attribute resolution on the back-channel in the Token and Userinfo endpoints are unable to resolve attributes based on session/authentication/client information, as it is unavailable. This places additional requirements on the resolver configuration to fail gracefully in such cases. As an alternative, there is an encodedAttributes profile configuration property that instructs the Authorize endpoint to encode the attributes needed in later phases into the Authorization Code and/or Access Token directly, making them available to the Token and Userinfo endpoints. This naturally increases the size of the code/token but for specific cases may be tolerable.
Reserved Claims
Because OIDC is string-based, rather than reliant on XML and URIs for uniqueness, there are a number of arbitrary claim names that need to be avoided and will not be produced if used:
- aud
- iss
- iat
- exp
- acr
- auth_time
- at_hash
- c_hash
- nonce
The "sub" claim is also semi-reserved but does come from your configuration. However it has to meet certain requirements and so cannot just contain arbitrary data without risking severe consequences to RPs. It is analagous to violating the expectations of a SAML SP regarding the content of an Attribute, but with more consistently severe problems. Please refer to the dedicated page at OPSubClaim for specifics.