The IdP's Attribute Resolver performs three main tasks: pulling in data from external systems (e.g., LDAP directories and relational databases), creating attributes from the pulled in data.
| Table of Contents | ||
|---|---|---|
|
Attributes and Encoders
An Attribute, within the IdP, is a protocol-agnostic data structure that contains:
a unique (within the IdP) identifier for the attribute
a set of localized names that can be displayed to the user
a set of localized descriptions that can be displayed to the user
a set of values for the attribute
a set of encoders that can transform the attribute in to a protocol-specific representation
For clarity, by protocol-agnostic we mean that within the IdP there is no special implementation of an Attribute for each given protocol supported by the IdP. For example, there is no such thing as a "SAML 2 Attribute" within the IdP. In a bit we will discuss the encoders used to transform attributes in to their protocol-specific formats.
...
The Attribute Mapper is the inverse of attribute encoding. These components inspect metadata (usually of the SP) to extract any SAML2 RequestedAttributes. These are decoded use the same configuration as the attribute encoders to produce produce IdPRequestedAttribute. This decoding includes not only the name changes (from the on-the-wire names to those used to configure the Attribute Resolver and Filter), but also types, as defined by the Attribute Encoders.
...
So, what actually happens when the resolver runs? How do all of these components fit together? The attribute resolution process goes like this:
Prerequested Attributes (TBD)
For each defined attribute definition:
if any dependency is listed, and has not yet been executed, it is executed
if no evaluation condition is given or a condition is given and it evaluates to true then proceed
the attribute definition is executed
the results of the execution are cached for the current request
For each data connector that is executed the process goes like this:
if any dependency is listed, and has not yet been executed, it is executed
if no evaluation condition is given or a condition is given and it evaluates to true then proceed
the data connector is executed
TBD exportAttributes will create the output attributes
the results of the execution are cached for the current request
It is important to note that as a result of this resolution process a data connector that is never directly, or transitively, a dependency of an attribute definition it will never be executed.
...
Parameters to the Attribute Resolution process are supplied by the AttributeResolutionContext class. In addition the AttributeResolverWorkContext is used as work space for the attribute resolution process; this context is entirely private to the attribute resolution process and is only of interest to those components such as components derived from one of the Resolver Plugins.
Programming Guide to Attribute Resolution
A web flow that wishes to invoke the Attribute Resolution subsystem must do the following.
Create an AttributeResolutionContext and populate it with appropriate parameters:
The canonical Prinicipal name
The entityID of the IdP and the SP
Optional ID of an authentication flow used
Additionally the precise names of the attributes resolved can also be set.
Locate an Attribute Resolver. This would usually be done via a ReloadableSpringService. See ReloadableConfiguration.
Call the resolver. After resolution, the result can be extracted via the getResolvedIdPAttributes() method and will usually be inserted into an AttributeContext.
If using a ReloadableSpringService. do not forget to call unpinComponent.