type="SimpleAggregation", this AttributeResolver supports a primitive form of aggregation of attributes from multiple sources of authority through the use of SAML 2.0 attribute queries using an identifier derived from the attributes obtained prior to this plugin executing. In other words, the original data is used as input to form follow-up requests to other sources.
This simple form of aggregation relies on a plain-text identifier (which could be pseudonymous but is still "seen" by the SP) as a "link" to accounts at other SAML attribute authorities. Furthermore, this plugin only supports the same forms of authentication usable when making primary attribute queries with the Query plugin. This includes mechanisms like client TLS, message signing, or some forms of HTTP authentication, but is not "presence-oriented"; that is, there is no proof supplied the user is "present" at the SP, so there are no constraints on when the SP could perform such queries.
Conceptually, you can think of this mechanism as equivalent to a networked set of LDAP or X.500 directories queried by DN, merely in SAML terms. It is, however, relatively easy to implement and support when there are batch processes in place for the exchange of identity data to establish the links. No user intervention is required, which is a plus for simplicity but a minus for privacy and user control.
After each query is performed, the resolver applies the attribute extractor and filter plugin(s) configured for the application before continuing with other queries and eventually returning the resulting attributes. Each filtering step will operate on only the attributes extracted as a result of a particular query, and the filter policies can be expressed in terms of the actual "issuer" of each set of attributes for fine-grained control.
This page refers to the following XML namespaces:
|SAML 2.0 Assertion namespace|
The following optional attributes are supported:
Optional identifier of a customized security policy to use when performing the query
|whitespace-delimited list of strings||Optional list of attribute IDs to search for a value to use as the identifier in the queries performed. The first attribute value found will be used as the value of the |
|URI||Optional value to use as the |
|boolean||false||If true, enforces SAML "strong matching" requirements on the subject of the resulting assertions. By default, each AA is trusted to return an assertion about the queried subject without explicitly comparing the result.|
Optional identifier of a special attribute to create in the event of a "transient" failure during the aggregation process. Errors are considered transient if they are caused by system outages or misconfiguration. If an IdP appears to support the query protocol, then transient errors include any failure to obtain a successful SAML response or a violation of security policy while processing the result.
If such errors occur, the attribute will contain one or more URL-encoded exception messages, and the application should be aware that not all of the "usual" attributes it might receive are available.
The following optional child elements are supported:
|0 or more||The value of the element is an |
|0 or more||The value of the element is the ID of an attribute available for the user. Each of the attribute's serialized values is interpreted as an |
|0 or more|
Supplies a set of attribute and value filters to include in any queries
|0 or 1||Supplies a dedicated MetadataProvider to use in place of the application-defined source.|
|0 or 1|
|0 or 1|
Note that the
<EntityReference> elements can be supplied in any order, and are processed in the order they appear, with a query attempt per