| Table of Contents |
|---|
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).
...
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.
...
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.
...
Note that it's optional and not required to "combine" SAML and OIDC rules together. The system is intelligent enough to allow multiple "outbound" rules associated with the same IdPAttribute id with different transcoders involved.
The additional supported properties and transcoder types are described below. As with SAML, OIDC includes mechanisms to request claims, and so the transcoders support bidirectional mappings to allow decoding of requested JSON claims as well as encoding of IdPAttributes into JSON.
Common Properties
In addition to the generic properties, all OIDC transcoders support the following:
Name | Type | Default | Description |
|---|---|---|---|
String | The claim name to map to and from (if absent, the IdPAttribute's id is used) | ||
oidc.asArray | Boolean | false | Encodes and decodes multiple values as a JSON array |
oidc.asInteger | Boolean | false | Encodes and decodes individual values as a JSON integer |
oidc.asBoolean | Boolean | false | Encodes and decodes individual values as a Boolean |
oidc.stringDelimiter | String | <space> | Encodes and decodes multiple values as a string with a specifie delimiter |
Transcoder Types
There are 3 built-in types of OIDC transcoders, as follows. Each one is predefined as a Spring bean for use in rules using the "short" name of the transcoder as shown.
...
The simplest and most commonly used transcoder, it supports encoding and decoding internal values from and to the StringAttributeValue class. It supports the following additional optional property:
Name | Type | Default | Description |
|---|---|---|---|
oidc.asObject | Boolean | false | Encodes and decodes a string value as a JSON object (meaning parsing to and from JSON) |
OIDCScopedStringTranscoder
Supports encoding and decoding internal values from and to the ScopedStringAttributeValue class. It supports the following additional properties (all optional):
Name | Type | Default | Description |
|---|---|---|---|
oidc.scopeDelimiter | String | @ | The character(s) to use to separate the value and scope |
OIDCByteTranscoder
Supports encoding and decoding internal values from and to the ByteAttributeValue class, with a base64 transform applied. It supports no additional properties.
...
The alternative to the generality of the transcoding approach is the older style of embedding <AttributeEncoder> elements within the AttributeResolverConfiguration to specify individual encoding of AttributeDefinitions to claims. This is supported for OIDC via a set of extensions that add new encoder plugin types.
| Note |
|---|
Note for upgraders: the older "token placement" settings that were supported here for splitting claims have been moved to profile configuration settings and are no longer valid here. |
...
Namespace: urn:mace:shibboleth:2.0:resolver:oidc
Schema: http://shibboleth.net/schema/oidc/shibboleth-attribute-encoder-oidc.xsd
...
All of the extension encoders support the common settings described on the AttributeEncoderPluginConfiguration page. They also support all of these common XML attributes:
Name | Type | Default | Description |
|---|---|---|---|
asObject | Boolean | false | Encodes (and decodes) string-valued data as a JSON object instead of a string value |
asBoolean | Boolean | false | Encodes (and decodes) values as booleans (anything but "true", ignoring case, is treated as false) |
asArray | Boolean | false | Encodes (and decodes) multiple values into a JSON array rather than a delimited string |
asInt | Boolean | false | Encodes (and decodes) values as JSON integers (non-numeric values are ignored) |
stringDelimiter | String | <space> | Sets the delimiter to use when encoding multiple values into a single JSON string |
The supported xsi:type values (and additional options) are:
xsi:type | Description |
|---|---|
oidc:OIDCString | Basic encoder for string-valued claims (defaults to encoding multiple values as a space-delimited string) |
oidc:OIDCScopedString | Encoder for scoped claims. A |
oidc:OIDCByte | Encoder for base64-encoding byte-valued data |
Examples
The expected JSON is shown in XML comments. Unrelated aspects are omitted such as dependencies and so forth.
...