StorageServiceConnector

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

1 Overview
2 General Configuration
- 2.1 Context/Key Template Contexts
3 Examples
4 Reference
5 Spring Configuration

Overview

The StorageService DataConnector generates results from a query against the IdP's StorageService API (see also StorageConfiguration). It's main value is in prototyping certain features that require persistent storage without the need for new code, and because the IdP includes an in-memory service by default, it's easy to use for testing with no extra configuration.

The interface to storage relies on lookup of a single record at a time, but the data connector also allows scriptable response handling that can parse the content of a storage record into multiple results, if the record is in a parseable form such as JSON.

General Configuration

The connector marries three essential pieces of configuration to be supplied by the deployer:

a StorageService bean
the two-part record lookup criteria (known as "context" and "key" in the storage model)
response processing

The lookup criteria are produced by evaluation of a pair of Velocity templates supplied with the <ContextTemplate> and <KeyTemplate> elements.

The two supplied response processing implementations consist of:

A simple mechanism that exposes the entire record content as a single attribute (configured with the generatedAttributeID setting to name the attribute).
A more complex approach using the <RecordMapping> element to supply a script to produce attribute data from the record arbitrarily.

At minimum, a storageServiceRef attribute must be supplied to provide the StorageService to use.

Context/Key Template Contexts

Several variables are available in the two template contexts. In practice, $resolutionContext.principal and various named dependent attributes (if any) tend to be most useful.

Name	Type	Description

Name	Type	Description
resolutionContext	AttributeResolutionContext	Commonly useful members include `$resolutionContext.principal` and `$resolutionContext.attributeRecipientID`
custom	Object	Optional object injected via `customObjectRef` attribute
foo, bar, etc.	List<IdPAttributeValue>	For each IdPAttribute available from all the provided dependencies, the attributes' values are available as a collection under the attribute's name.

Examples

Any examples here omit the Spring beans that define the StorageService to use. This service may be one used for other purposes within the IdP, or may be defined specifically for this purpose.

 <DataConnector id="storageConnector" xsi:type="StorageService"
		storageServiceRef="shibboleth.StorageService"
		generatedAttributeID="storageRecord">
	<ContextTemplate>org.example</ContextTemplate>
	<KeyTemplate>$resolutionContext.principal</KeyTemplate>
	<ResultCache expireAfterWrite="PT5M"/>
</DataConnector>

Reference

Spring Configuration

Native bean IDs can be injected as follows:

The StorageService instance is injected via the storageServiceRef attribute.
The builder for the query can be specified as an externally defined bean via the executableSearchBuilderRef attribute (as a replacement for the <ContextTemplate> element and related elements). This allows for complete generality of the query-building process.
The processing of the response can be specified with an externally defined bean via the mappingStrategyRef attribute (as a replacement for the <RecordMapping> element).
The caching of results can be specified as an externally defined bean via the <ResultCacheBean> element (as a replacement for the <ResultCache> element).
Rarely, a non-default Velocity engine can be injected via the templateEngine attribute.