The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.

TemplateAttributeDefinition

The Template attribute definition generates output values by merging the input values of its source attributes into a Velocity template string (essentially an inline template).

All the input attributes must contain the same number of input values (null or empty values take up a spot and are included in this count).

Schema Name and Location

This xsi:type is defined by the urn:mace:shibboleth:2.0:resolver namespace 3.3, the schema for which can be located at http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd

Prior to V3.3 supplied plugins were defined by a schema type in the urn:mace:shibboleth:2.0:resolver:ad namespace, the schema for which is located at http://shibboleth.net/schema/idp/shibboleth-attribute-resolver-ad.xsd. This is still supported, but every element or type in the old 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.

Attributes

Any of the common attributes can be specified.

In addition, the velocityEngine attribute may be used to point to a an externally defined (using native spring syntax) velocity engine, but this is rarely needed.

Child Elements

Any of the common child elements can be specified. In addition the following elements are supported:

NameCardinalityDescription
<Template>
0 or 1The template to use. If a template is not provided, then the output value is produced by appending the input values of each of the input attributes in the order in which they are declared as sources, but this is a DEPRECATED approach.

Note that it's usually an anti-pattern to use a <InputDataConnector>  with the allAttributes property, because this will only work correctly if all the inputs have the same number of values. If you have result sets (e.g. from LDAP) that don't satisfy this rule, just make sure to enumerate the attributes you need. This used to be handled with an extra configuration element called <SourceAttribute> but this is no longer needed because of the new dependency syntax.

Example

<AttributeDefinition id="template" xsi:type="Template">
    <InputAttributeDefinition ref="OtherAttr" />
    <InputDataConnector ref="myLdap" attributeNames="attrFromLdap" />

    <ad:Template>${attrFromLdap}::${OtherAttr}</ad:Template>

    <AttributeEncoder xsi:type="SAML2String" name="https://example.org/example/name" friendlyName="templated" />

</AttributeDefinition>