File(s): conf/attribute-resolver.xml, idp.properties
Format: Custom Schema
Attribute resolution is the process of collecting data about the subject (generally after, but sometimes also during) authentication so that it can be used to implement policy and then to provide a subset of that information to relying parties. Most, if not all, of the user-specific content in the messages that are created by the IdP come from this process.
The resolver service is essentially a meta-directory. It doesn't hold information but it contains a directed graph of attribute definitions and data connectors that collect information from a variety of sources, combine and transform it, and produce a final collection of IdPAttribute objects, which are an internal representation of user data not specific to SAML or any other supported identity protocol.
You can exercise and debug the behavior of this process using the AACLI tool or the web interface it uses. This is particularly helpful if you're making changes, performing upgrades, etc., to validate the results match in any given case.
In older versions of the IdP, the resolver service was also responsible for attaching so-called AttributeEncoders to the objects that were subsequently used to produce the protocol-specific "encoding" of the data into SAML and other formats.
This is still supported, but with a few exceptions, a better approach in V4 is to rely on a common set of encoding rules contained in the new AttributeRegistryConfiguration based on reasonable conventions for the names of the IdPAttribute objects. For example, if you just accept that you should put the subject's e-mail address into an IdPAttribute called "mail", then the registry knows how to encode that into SAML automatically using the name prescribed by the standard.
In a typical (and default) configuration, only one configuration resource is supplied for controlling attribute resolution, a file called attribute-resolver.xml. All such resources must contain a "root" element named
> defined in the
urn:mace:shibboleth:2.0:resolver XML namespace.
The example below includes an
xsi:schemaLocation attribute that should allow for use of XML-aware editors, but there is no runtime dependency on the web server hosting those schemas, provided this exact location is the one used. All of the examples shown assign attribute IDs that correspond to pre-existing encoding rules from the default supplied registry.
Formally, this is the configuration of the "AttributeResolver" service. By default one file, attribute-resolver.xml, defines the attributes to be resolved. Multiple files can be specified by editing the bean referred to by the property
idp.service.attribute.resolver.resources (default value
shibboleth.AttributeResolverResources in the services.xml file) or changing the property to a different bean name.
The top level
> element has one attribute,
id, which is used purely for logging.
The following child elements may appear:
|any||Defines connections to sources of data which provide input to attribute definitions. These data sources are usually external (databases or attribute stores). It is also now possible when desired to directly export data from a connector without layering attribute definitions on top.|
|any||Allows more precise formatting and transformations of input data into single attributes, as well as pre-V4 support for attaching encoders and other descriptive characteristics. Many use cases can now be handled without attribute definitions.|
The attribute-resolver.xml file can also use property replacement to externalize particular settings such as passwords. Some common/global properties, such as idp.scope, are defined in the idp.properties file, and you may add your own properties and files. See the SpringConfiguration topic for more on property syntax.
The properties which affect the resolution process are names starting with idp.service.attribute.resolver. as described here.