The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

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

Version 1 Next »

Crypto Transient ID Attribute Definition

Available in version 2.3 and later, this attribute definition produces a cryptographically verifiable opaque identifier that can later be mapped back to the user by a CryptoTransient principal connector.

Using cryptographic transient identifiers allows multiple IdP nodes that share a symmetric key to produce and consume identifiers without sharing state. This is part of a stateless clustering solution.

Provide a DataSealer

The cryptographic settings needed for this plugin are supplied by a DataSealer, a Java bean component that you configure and then inject into the resolver.

Define the Definition

A crypto transient ID attribute definition starts with the same <resolver:AttributeDefinition> element as all other attribute definitions and has a type attribute of xsi:type="ad:CryptoTransientId".

Each definition must also have an id attribute that assigns it an unique, among attribute definitions, identifier used to refer to defintion within the rest of the attribute resolver configuration.

It must also contain a dataSealerRef attribute that identifies a DataSealer Spring-configured bean. It may contain a lifetime attribute controlling the length of time the identifier will be valid. This time limit is also encrypted into the value.

Crypto Transient ID Attribute Definition
 
<resolver:AttributeDefinition id="UNIQUE_ID" dataSealerRef="shibboleth.TransientIDDataSealer" lifetime="PT3M" xsi:type="ad:CryptoTransientId"> 

<!-- Remaining configuration from the next step go here --> 

</resolver:AttributeDefinition> 

While this attribute definition can have dependencies, like all other attribute definitions, they are never used. The transient ID comes exclusively from internal IdP state.

  • No labels