Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

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

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.

 XML Attributes

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.

 XML Elements

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.

  • No labels