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 7 Current »

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

Overview

DataConnectors produce sets of IdPAttribute objects which are internal to the IdP and are generally used as input to attribute definitions or are exported directly as resolver results.

DataConnector output was not historically passed along directly to relying parties, but this can be accomplished via the exportAttributes option. This works for eventual use in SAML (and other protocol) responses if the AttributeRegistryConfiguration approach to producing the proper encodings is used rather than the legacy use of AttributeEncoders.

Error Handling and Failover

A critical step in configuring most DataConnectors is adjusting settings to ensure errors are handled. There are a wide range of control points available to determine whether a connector "fails" in a visible fashion or simply returns no data.

In addition, when a connector does actually report failure, you can configure a single <FailoverDataConnector> element so that an alternative DataConnector runs in its place. The results of the failover connector are reported as the results of the original so that defintions that depend on the original don't know the difference. This can be chained ad nauseum. A StaticDataConnector is a common "last resort" to use since they cannot fail.

DataConnector Plugin Types

A DataConnector is defined using the (naturally) <DataConnector> element, but each type of connector is distinguished by its "XML schema type", which is carried by the xsi:type XML attribute.

The following types are supported:

xsi:type

Description

Static

A data connector that gets its information from a static list of attributes and values specified within the configuration

ScriptedDataConnector

Creates multiple attributes from a script supported by JSR-223

ComputedId

Creates an attribute whose value is computed from the SHA-1 hash of the requesting entity's ID, an attribute value (usually a user identifier of some kind), and a salt

StoredId

Creates an attribute whose value is generated either via the ComputedId mechanism (above) or by storing it and looking it up in a database

PairwiseId

Extension alternative to ComputedId/StoredId using a Spring-defined PairwiseIdStore

RelationalDatabase

A data connector that uses JDBC to connect to and pull information from a relational database

LDAPDirectory

A data connector that uses LDAP to connect to and pull information from a directory

HTTP

A data connector that uses HTTP to connect to and pull information from a web service

Subject

A data connector that operates as a pass-through mechanism for IdPAttribute objects carried inside custom IdPAttributePrincipals produced from external/proxied authentication flows.

StorageService

A data connector that pulls a record from a StorageService instance

EntityAttributes

A data connector that exposes metadata tag extensions as IdPAttribute objects

Reference

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

 Common XML Attributes

Name

Type

Default

Description

id

String


Identifier for the DataConnector. This is used for logging, to establish dependencies, and as a target for failover.

activationConditionRef

Bean ID


Bean ID of a condition to decide whether to resolve this connector, see here.
Mutually exclusive with relyingParties and resolutionPhases and variants

relyingParties

Space-delimited list


List of entity IDs for which this connector should be resolved.
Mutually exclusive with activationConditionRef

excludeRelyingParties

Space-delimited list


List of entity IDs for which this connector should not be resolved.
Mutually exclusive with activationConditionRef

resolutionPhases

Space-delimited list


List of resolution phases (i.e. flows) during which this connector should be resolved.
Mutually exclusive with activationConditionRef

excludeResolutionPhases

Space-delimited list


List of resolution phases (i.e. flows) during which this connector should not be resolved.
Mutually exclusive with activationConditionRef

exportAttributes

Space-delimited list


List of attributes produced by the DataConnector that should be directly exported as resolved IdPAttributes without requiring actual AttributeDefinitions.

In the case of a name clash (a DataConnector exports an attribute with the same name as an AttributeDefinition, or another DataConnector exports the same attribute) the DataConnector attribute is NOT added and a warning issued.

noRetryDelay

Duration

0

Time between retries of a failed DataConnector (during the interval, failure is just assumed when the connector is run and no actual connection is attempted)

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 the data connector returns no attributes.

 Common XML Elements

Name

Cardinality

Description

<InputAttributeDefinition>

0 or more

This element identifies an attribute definition which is an input to this data connector

<InputDataConnector>

0 or more

This element identifies a data connector whose attributes are to be input to this data conector

<FailoverDataConnector>   

0 or 1

This element has a single attribute ref="whatever" whose content is the identifier of a data connector to resolve if this data connector fails (for instance due to the external data source being unavailable)

Native Spring Configuration

Some DataConnectors can be configured using native Spring syntax, which allows for various optimizations, shared connection configuration, and/or use of very advanced options not supported by the custom XML syntax more commonly used.

Two mechanisms for this exist:

  • By direct reference to externally defined beans, for instance the <BeanManagedConnection> element, which is the most common way of defining a shared database connection.

  • In much more unusual cases, by specifying XML resources via specific attributes that contain appropriate low-level definitions for a connector’s “component” parts.

More precise details are described for each DataConnector that has this capability.

  • No labels