...
There are a small set of generic properties, some required and some optional. The "Type" refers to the underlying object that the system expects to be able to produce as a value of the property, but String is almost always a supported format to use for convenience.
Name | Req? | Type | Description |
|---|---|---|---|
id | Y | String | The IdPAttribute id/name that is used internally. This dictates when the rule will be applied to attributes within the IdP for outbound encoding, as well as what to call an attribute created during inbound decoding. |
transcoder | Y | Space-delimited list of Bean IDs, or an AttributeTranscoder | This defines which AttributeTranscoder objects should be used to encoder and decode data when the rule runs, and dictates most of the rest of the properties that will be required or supported. In most cases this is expressed by specifying one or more Spring bean IDs in a list; the implementation will turn those into the right objects if they exist. |
activationCondition | Predicate<ProfileRequestContext> or a Bean ID | Standard across the system, this is a condition to evaluate at runtime to control whether to apply the rule | |
encoder | Boolean | Defaults to true, can be set false to limit use of the rule to decoding only | |
decoder | Boolean | Defaults to true, can be set false to limit use of the rule to encoding only | |
relyingParties | Collection<String> or a space-delimited list of Strings | Shortcut for applying an activation condition that matches a set of relying party names against the request | |
displayName[.lang] | String | Language-specific values to use as display names for the IdPAttribute | |
description[.lang] | String | Language-specific values to use as descriptions for the IdPAttribute |
The latter two are optionally language-aware; if the raw property name is used, then the corresponding value is used any time the default Locale is in effect for a request. Otherwise a dot separator must be followed by a language code, which may also include country code.
...
Other Examples
Non-Standard Naming
While I would strongly we advise against doing so, you will run into constrant constant pressure from vendors to support one-off Attribute names. When you agree to do that, you should understand that it won’t stop, and you will end up over time with dozens of these rules to maintain and a brittle configuration prone to problems. Standards exist for that reason.
...
This is merely an alternative approach to using an AttributeEncoder to do the same thing, just outside instead of inside the resolver configuration.
Metadata-Driven Naming 5.1
Yet another way to handle exception-based naming rules is with SAML metadata. Each set of transcoders for a protocol supports its own property for instructing the system to check for a metadata “tag” extension that carries values specifying naming rules specific to that SP. This approach only applies to encoding of data, not decoding. Refer to the protocol-specific transcoder topics linked above for the details and examples.