DataConnectorConfiguration
- Scott Cantor
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 |
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.
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.