ScopedAttributeDefinition

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

1 Overview
2 Reference
3 Examples

Overview

The Scoped AttributeDefinition applies a (fixed) scope, typically a domain-valued suffix, to an input attribute's values. The resulting attribute's values are of type ScopedStringAttributeValue.

Reference

Exactly one of these two attributes must be present:

Name	Type	Description

Name

Type

Description

scope

String

Provides the scope/suffix to add. In the example/default configuration, the scope value is pulled from the idp.scope property in conf/idp.properties

scopeFromDependency ^4.1

String

The ID of an attribute definition to be used as a the scope. This attribute scopeFromDependency MUST

be specified as a <InputAttributeDefinition> (in addition to any other Input dependencies)
have exactly one value
which must be a String

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^4.1	Space-delimited list		List of entity IDs for which this Attribute Definition should not be resolved. Mutually exclusive with `activationConditionRef`
resolutionPhases^4.1	space-delimited list		List of resolution phases (i.e. flows) during which this Attribute Definition should be resolved. Mutually exclusive with `activationConditionRef`
excludeResolutionPhases^4.1	space-delimited list		List of resolution phases (i.e. flows) during which this Attribute Definition should not be resolved. 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.
profileContextStrategyRef	Bean Reference		DEPRECATED in 4.3 Bean ID of a function injected to override the normal lookup process for the request's ProfileRequestContext

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.

Examples

<AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
    <InputAttributeDefinition ref="uid" />
</AttributeDefinition>

<AttributeDefinition id="eduPersonScopedAffilition" xsi:type="Scoped" scopeFromDependency="upStreamIdP">
    <InputAttributeDefinition ref="affitional" />
    <InputAttributeDefinition ref="upStreamIdP" />
</AttributeDefinition>