Page Comparison

File(s): conf/attribute-registry.xml, conf/attributes/default-rules.xml, conf/attribute-resolver.xml, conf/attributes/custom/
Format: Native Spring XML

...

The Attribute Registry service is a new addition to V4 that provides a more advanced way to configure the relationship between the internal IdPAttribute objects that are (for the most part) produced by the Attribute Resolver and the way the data is represented in the protocols supported by the software like SAML, CAS, or in the future OIDCOpenID.

In the case of SAML, at least, the actual XML representations and the names used are decoupled from the internal state. The Attribute Registry was designed to address the mapping of data between formats independently of the Attribute Resolver, which is chiefly concerned with how to get data and not how to encode it.

Historically this was addressed with the concept of Attribute Encoders, which were "attached" by the Attribute Resolver to the IdPAttribute objects it produces via Attribute Definitions so the rest of the system could properly encode the XML. This works reasonably well in a lot of cases, and remains supported (though the code under the covers has been completely replaced in this version). We have no plans at present to deprecate this approach.

The purpose of this new registry service is to support additional use cases that were not well, if at all, supported by the old design, such as:

• proxying of attributes obtained from external SSO providers that aren't exactly sourced from the Attribute Resolver

• mapping of SAML (or other protocols) into internal data, such as in the case of <RequestedAttribute> elements in SAML metadata

• in many cases, eliminating the need for the SimpleAttributeDefinition plugin if used solely to attach encoders

Using the Attribute Resolver's configuration to express mapping rules gets very awkward or even impossible if there are no scenarios in which the data would ever be produced by it.

...

New installs load a default set of rules from conf/attributes/default-rules.xml to use for a common/standard set of attributes, this . This contains rules for encoding and decoding of common attributes. 

Additionally the configuration loads conf/attribute-resolver.xml. The default resolver does not specify any attribute encoders, but importing referencing the file allows use of encoders for exceptional cases if you prefer to use them.

...

Upgraded systems with an older services.xml file are configured internally to load only conf/attribute-resolver.xml  the existing AttributeResolverConfiguration resources in order to process the <AttributeEncoder> elements within it in order to produce a compatible set of rules to use. The default set of rules supplied with the software is not loaded in order to prevent any changes in behavior, including duplication of encoded attributes.

The default resource set after upgrades is meant as a compatibility baseline. Once a determination on the desired approach to configure behavior in the future is made, upgraded systems can be adjusted to add in a shibboleth.AttributeRegistryResources bean and an explicit decision made as to what resources to load by editing services.xml to do so.

...

The mapping rules that make up the registry are referred to as "transcoding rules" because they support both encoding and decoding attributes to and from e.g., SAML, thus the plugins that support this are called AttributeTranscoders. The mappings are turned into objects of the class TranscodingRule, which are indexed in a variety of ways to enable the system to find the right rules to map to and from the various supported objects.

The system is designed with a high degree of flexibility for defining and loading the mapping rules, but the primary mechanism defined for now is based on properties or maps keyed by some pre-defined strings. Most often the map values will also be strings, which allows use of a Java property file as as an alternative way of defining a rule without using XML.

...