StorageServiceConnector
Namespace: urn:mace:shibboleth:2.0:resolver
Schema: http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd
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 |
---|---|---|
resolutionContext | Commonly useful members include | |
custom | Object | Optional object injected via |
foo, bar, etc. | 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.