Namespace: urn:mace:shibboleth:2.0:resolver


The RelationalDatabase DataConnector generates multiple IdPAttribute objects from a relational database via a JDBC DataSource. The results are generated such that each IdPAttribute represents a column of the query result set. The ordered values represent the rows of the result set and each IdPAttribute will contain the same number of values, including any embedded nulls in the results. Nulls are represented explicitly with objects of type EmptyAttributeValue as placeholders within the ordered lists.

Data Sources and Drivers

This connector uses a JDBC DataSource to connect to the database. This can be supplied via a few different techniques, but the recommended approach is to define one using Spring syntax in global.xml (or similar location) and use the <BeanManagedConnection> element, the reason being it can be easily shared across multiple connectors. If you need the ability to reload the data source's settings, then the suggested approach is to create a new Spring file to contain the bean, and add it to the set of AttributeResolverConfiguration resources in services.xml

No matter where or how you define the data source, it is your responsibility to obtain and install the JDBC driver you want to use. The IdP does not come with any drivers, to avoid them becoming stale.

Whatever driver you use should generally be installed to edit-webapp/WEB-INF/lib, after which you will need to stop your container, rebuild the warfile, and restart the container. Failure to do so will lead to ClassNotFound exceptions that reference the driver class.

Connection Pooling

If you want to use connection pooling, the Apache DBCP library is included with the IdP. The DBCP library provides various DataSource implementations that wrap an actual database driver, and you will have to add the driver itself as well. A rudimentary example is included below, but be aware that there are a lot of options available and no particular "best practice" is implied by our limited experience with them.

Read Only Connections

Previous versions of the IdP marked the connections used for attribute resolution as read-only. A configuration attribute was provided to override this behavior and allow connection pools to be shared between the RDBMS Data Connector and other read-write uses.  In V4, the DataConnector no longer marks the connections as read-only itself.  If you want to enforce read-only behavior, you should do so via the JDBC connection URL and/or limiting the access of the service account.













Controls whether an empty result set is an error




Whether a failure when verifying the database's availability during startup is fatal (stops the Attribute Resolver service from starting)




Timeout for the queries made against the database




Controls whether a result set with more than one row is an error


Bean ID


Bean ID of a MappingStrategy<java.sql.ResultSet> to process the result set in a pluggable way


Bean ID

Bean ID of a Validator to control what constitutes an initialization failure (set this to "shibboleth.NonFailFastValidator" to bypass connection attempt at config load time)


Bean ID


Bean ID of an ExecutableSearchBuilder<ExecutableStatement> to produce the SQL query to execute


Bean ID


Bean ID of a to use for processing the SQL template








Exactly 1

Not permitted if the springResource attribute is used

Connects to a database via a JNDI DataSource defined in the container


Connects to a database via a JDBC DataSource defined explicitly with a simplified syntax.


Connects to a database via an externally specified DataSource


0 or 1

The template of the SQL query to send to the database


0 or more

A series of remapping definitions which map a column name to an IdPAttribute ID



0 or 1

Defines how results should be cached


Bean ID (in the element content) defining how results should be cached as an externally defined<String,Map<String,IdPAttribute>> 

Spring Configuration

Native bean IDs can be injected as follows:

  1. The DataSource can be specified as an externally defined bean via the <BeanManagedConnection> element (as a recommended replacement for the the <ContainerManagedConnection> element).

  2. The builder for the SQL query can be specified as an externally defined bean via the executableSearchBuilderRef attribute (as a replacement for the <QueryTemplate> element).

  3. The mapping of column names can be specified as an externally defined bean via the mappingStrategyRef attribute (as a replacement for the <Column> elements).

  4. The caching of results can be specified as an externally defined bean via the <ResultCacheBean> element (as a replacement for the <ResultCache> element).

  5. A Validator can be specifier as as an externally defined bean via the validatorRef attribute.

  6. Rarely, a non-default Velocity engine can be injected via the templateEngine attribute.


Simple DataConnector entirely in custom syntax
Simple Data Connector using external bean

The example below demonstrates a number of approaches:

  • Use of a Spring file to define the various low-level objects, which could be referenced via
    <DataConnector" xsi:type="RelationalDatabase" springResources="....." />

  • Use of a Spring file to define a data source which could be referenced via

  • Use of the DBCP pooling library to wrap a database driver in a simple pool.

Example of a springResources file