AttributeDefinitionConfiguration

Namespace: urn:mace:shibboleth:2.0:resolver
Schema: http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd

1 Overview
2 AttributeDefinition Plugin Types
- 2.1 Simple
- 2.2 PrincipalName
- 2.3 Scoped
- 2.4 Prescoped
- 2.5 RegexSplit
- 2.6 ScriptedAttribute
- 2.7 Mapped
- 2.8 Template
- 2.9 SubjectDerived
- 2.10 ContextDerived
- 2.11 Decrypted
- 2.12 DateTime
3 Reference

Overview

AttributeDefintions produce a single IdPAttribute object, a neutral/internal representation of data. These objects eventually become SAML Attributes, OIDC claims, or other protocol-specific represenations through a process called "encoding". Encoding rules are established either through generic rules established via the AttributeRegistryConfiguration or, as in older versions, by attaching AttributeEncoder plugins within the Attribute Definition.

The ability to attach encoders is what distinguishes the product of an AttributeDefinition from an IdPAttribute produced by DataConnectors, so the difference has started to become somewhat historical with the new registry service providing a more generic facility.

Attribute definitions may also, but need not, be based on the output of a DataConnector, and often transform their input.

AttributeDefinition Plugin Types

An AttributeDefinition is defined using the <AttributeDefinition> element, but each type of definition is distinguished by its "XML schema type", which is carried by the xsi:type XML attribute.

The following types are supported:

xsi:type	Function

xsi:type	Function
Simple	Copies an input attribute to an output attribute. Typically this was used to 'expose' attributes sourced from a DataConnector, and is often superfluous now with the ability to export attributes from them directly.
PrincipalName	Exposes the subject's canonicalized principal name as a single-valued attribute
Scoped	Applies a (fixed) scope to the input attribute's values
Prescoped	Splits input attribute values into values and scopes
RegexSplit	Splits input attribute values according to a regular expression
ScriptedAttribute	Generates an attributes using a JSR-223 script
Mapped	Allows many to many mapping of input values to output values according to regular expression mapping rules
Template	Feeds the input values (potentially from multiple input attributes) into a Velocity template to construct output values
SubjectDerived	Extracts individual attribute data from authenticated Subject(s), this is frequently better handled now by the Subject DataConnector
ContextDerived	Extract arbitrary data from the request context via a Function bean
Decrypted	Decrypt input values using a DataSealer
DateTime	Convert string input values into date/time values

Reference

All connectors support a set of common XML Attributes and Elements for configuring common behavior.

Name	Type	Default	Description

Name	Type	Default	Description
id	String		Identifier for the IdPAttribute as well as its definition. This is used for logging and to establish dependencies and relationships between connectors and definitions, and to reference the data item in filter rules and many other configuration features. Note that the value MUST NOT contain whitespace, and use of certain other special characters will result in warnings that should be addressed in case the rules are made more strict in future versions.
activationConditionRef	Bean Reference		Bean ID of a condition to decide whether to resolve this definition, see here. Mutually exclusive with `relyingParties` and `resolutionPhases` and variants
relyingParties	Space-delimited list		List of entity IDs for which this Attribute Definition should be resolved. Mutually exclusive with `activationConditionRef`
excludeRelyingParties	Space-delimited list		List of entity IDs for which this Attribute Definition should not be resolved. Mutually exclusive with `activationConditionRef`
resolutionPhases	space-delimited list		List of resolution labels for which this Attribute Definition should be resolved; this corresponds to values that are sometimes set in the AttributeResolutionContext’s “resolutionLabel” field. Mutually exclusive with `activationConditionRef`
excludeResolutionPhases	space-delimited list		List of resolution labels for which this Attribute Definition should not be resolved; this corresponds to values that are sometimes set in the AttributeResolutionContext’s “resolutionLabel” field. Mutually exclusive with `activationConditionRef`
dependencyOnly	Boolean	false	If set to true, the attribute is not exposed outside the resolution process and is available solely within the resolution process
preRequested	Boolean	false	If set to true, the attribute (and its dependencies) will be resolved in pre-pass and its value made available to other definitions' ActivationConditions. See PreRequestedAttributes for details.
propagateResolutionExceptions	Boolean	true	Whether connector/plugin failure is fatal to the entire attribute resolution process. If this is set to false the error is logged and no values are returned for this attribute.

Name	Cardinality	Description

Name	Cardinality	Description
<InputAttributeDefinition>	0 or more	This element identifies an attribute definition which is an input to this attribute definition.
<InputDataConnector>	0 or more	This element identifies a data connector whose attributes are to be input to this attribute definition.
<AttributeEncoder>	0 or more	An inline definition of how an attribute will be encoded for inclusion in a message to a relying party. These are distinguished by an `xsi:type` attribute, and the different types are documented here. Replaceable via the more generic AttributeRegistryConfiguration.
<DisplayName>	0 or more	A human readable name for this attribute. This name may, for example, be displayed to the user to consent to the attribute's release. If multiple display names are used, then they should bear an `xml:lang` attribute to distinguish them. Replaceable via the more generic AttributeRegistryConfiguration.
<DisplayDescription>	0 or more	A human readable description of for this attribute. This name may, for example, be displayed to the user to consent to the attribute's release. If multiple display descriptions are used, then they should bear an `xml:lang` attribute to distinguish them. Replaceable via the more generic AttributeRegistryConfiguration.