AttributeInMetadata type is a Matcher which filters results based on
<md:RequestedAttribute> elements within the request-indicated
<md:AttributeConsumingService> in the SP's metadata. The parameterization controls
- Whether the
<md:RequestedAttribute>naming is applied directly or inferred from a rudimentary algorithm based on the IdP's attribute encoding rules (
- The behavior when the metadata contains no
- The behavior with respect to the
- Whether this is a Matcher or a PolicyRule (via
Value matching is purely string-based. Only string attribute values of the input attribute are inspected and they are compared with a string representation of each of the values in the
RequestedAttribute. Only matching values are added to the Permit or Deny List.
AttributeInMetadata or MappedAttributeInMetadata?
Schema Type and Location
AttributeInMetadata type is defined in the
urn:mace:shibboleth:2.0:afp namespace, the schema for which can be located at http://shibboleth.net/schema/idp/shibboleth-afp.xsd
saml:SAMLAttributeInMetadata type is defined in the
namespace, the schema for which can be located at http://shibboleth.net/schema/idp/shibboleth-afp-mf-saml.xsd
|String||optional||If this attribute is present, a |
If this attribute is present, provides additional filtering of the
Use of the
|Boolean||false||If true then all input values are returned if and only if the metadata contains no |
true (erroneously false in release prior to 3.2, see here)
|If this is true and the corresponding |
|String||optional||If this attribute is present, then this is a PolicyRule returning true if the Matcher, when applied to the attribute with this ID, matches any values. See AttributeValueString for an exmaple of how attributeID changes the meaning of a Matcher in a slightly less daunting scenario.|
Suppose an SP has the following requested attributes in metadata:
Then an IdP >= v3.2 with the following configuration will release eduPersonPrincipalName and mail as wire attributes to the above SP provided that they are configured with attribute encoders that match the SAML naming above. An IdP <v3.2 will release displayName additionally.
Now suppose an SP has the following requested attributes in metadata:
Then two IdPs with the following configurations will release the indicated wire attributes to the above SP:
Note that both IdPs have an attribute release policy that relies on the same set of requested attributes, but the requested attributes are mapped to different wire attributes in each case.