This data connector was historically used to produce both the "eduPersonTargetedID" SAML Attribute, which contains a SAML
<NameID> element in its values, and to generate SAML 2.0 "persistent" NameID values. The attribute use case is itself generally deprecated because SAML 1 itself is a legacy standard and because the use of the attribute in SAML 2 is both redundant, and overly complex. The NameID use case has been replaced by an equivalent NameID "generator" (see the NameIDGenerationConfiguration topic).
The connector remains supported to facilitate future compliance with emerging profiles for SAML subject identification the Shibboleth community hopes will replace the older options.
StoredId data connector generates an attribute whose value is persistent, opaque, and unique per user, per relying party. The value generated is stored in a database, which allows features such as reverse-lookup that are not supported by the ComputedIdConnector, but at the additional cost of a read/write data store that must be highly available.
The source attribute value and relying party are looked up in a table named
shibpid, and if a value is found, it is returned. Otherwise, if a salt is provided, then an initial value is calculated as for the ComputedIdConnector. If no salt is provided, then a random value is generated. In either case, the result is stored in the database for future use.
Schema Name and Location
xsi:type is defined by the
urn:mace:shibboleth:2.0:resolver schema 3.3, located at http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd.
Prior to V3.3 supplied plugins were defined by a schema type (xsi:type) in the
urn:mace:shibboleth:2.0:resolver:dc namespace, the schema for which is located at http://shibboleth.net/schema/idp/shibboleth-attribute-resolver-dc.xsd. This is still supported, but every element or type in the
urn:mace:shibboleth:2.0:resolver:dc namespace has an equivalently named (but not necessarily identical) version in the
urn:mace:shibboleth:2.0:resolver namespace. The use of the
urn:mace:shibboleth:2.0:resolver namespace also allows a relaxation of the ordering requirements of child elements to reduce strictness.
Any of the common attributes can be specified. In addition the following attributes are supported:
ID of the IdPAttribute used as input to the connector
In Version 3.4 a Warning about deprecation will be issued. This can be ignored (the attribute is required by the schema). However this attribute will be removed in V4. and the source attribute supplied using
|string||ID of the connector||ID of the IdPAttribute generated|
|string||Salt, of at least 16 bytes, used in computing initial values|
|string||BASE64||Controls the eventual text encoding of the value, this should be set to "BASE32" for new deployments (see the warning box about case sensitivity under PersistentNameIDGenerationConfiguration)|
XML Duration or a number of milliseconds
|PT5S||Timeout for the queries made against the database|
|integer||3||Number of retries if insertion fails due to database transaction bugs|
|boolean||false||Whether to strictly verify the database's availability and primary key during startup|
|space-delimited list of strings||23000 23505||SQLState codes to treat as retryable errors indicating a duplicate insert due to database transaction bugs|
Deprecated, use the <BeanManagedConnection> element instead
Any of the common child elements can be specified. In addition, one of the following may be provided if the deprecated
springResource attribute is not provided.
0 or 1 (all elements)
|Connects to a database via a JNDI resource defined in the container|
|Connects to a database via a JDBC data source configured explicitly|
|Connects to a database via an externally specified DataSource|
The database definition required is the same as that described in the PersistentNameIDGenerationConfiguration documentation. You can (and usually should) share a data source definition between that mechanism and this deprecated mechanism by defining the data source globally and referencing it via the
Spring Configuration 3.1
You can use the
<BeanManagedConnection> to specify a data source defined separately.