...
The files to load are specified by editing the bean referred to by the property idp.service.attribute.registry.resources or changing the property to a different bean name. There are two separate defaults, one for new installs ("shibboleth.AttributeRegistryResources"), and one for upgraded systems ("shibboleth.LegacyAttributeRegistryResources").In both cases the
The "machinery" for the configuration is spread between a system file and conf/attribute-registry.xml, and a directory for custom mapping rules (discussed later) is reserved in conf/attributes/custom/
...
Additionally the configuration loads conf/attribute-resolver.xml. The default resolver does not specify any attribute encoders, they can be useful in the case where you need to associated an activation condition with the precise formatbut importing the file allows use of encoders for exceptional cases if you prefer to use them.
Upgrades
Upgraded systems do with an older services.xml file are configured internally to load only load conf/attribute-resolver.xml 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 are is not loaded in order to prevent any changes in behavior.
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 could have the property changed by hand to point to "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.
Another note on upgrades is that in the unlikely event that you have any attribute display name or description metadata present for an attribute definition but do not have an encoder, the compatibility support is not going to attach that display metadata to the resulting attribute. This does not seem like a likely scenario, but it doesn't matter as long as the right files are loaded's a change.
Transcoding Rules
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.
...