Page tree
Skip to end of metadata
Go to start of metadata

File(s): conf/attribute-resolver.xml, idp.properties
Format: Custom Schema
Namespace: urn:mace:shibboleth:2.0:resolver
Schema: http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd

Overview

Attribute resolution is about specifying how attributes are to be constructed and then encoded prior to being sent on to a relying party.

You can exercise and debug the behavior of this process using the AACLI tool or the web interface it uses. This is particularly helpful if you're making changes, performing upgrades, etc., to validate the results match in any given case.

In a typical (and default) configuration, only one configuration resource is supplied for controlling attribute resolution, a file called attribute-resolver.xml. All such resources must contain a "root" element named <AttributeResolver> defined in the urn:mace:shibboleth:2.0:resolver XML namespace.

The example below includes an xsi:schemaLocation attribute that should allow for use of XML-aware editors, but there is no runtime dependency on the web server hosting those schemas.

Simple attribute-resolver.xml file
<AttributeResolver
        xmlns="urn:mace:shibboleth:2.0:resolver" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd">


    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->

    <!--
    The EPPN is the "standard" federated username in higher ed.
    For guidelines on the implementation of this attribute, refer
    to the Shibboleth and eduPerson documentation. Above all, do
    not expose a value for this attribute without considering the
    long term implications. 
    -->
    <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
        <InputAttributeDefinition ref="uid" />
        <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />
    </AttributeDefinition>

    <!--
    The uid is the closest thing to a "standard" LDAP attribute
    representing a local username, but you should generally *never*
    expose uid to federated services, as it is rarely globally unique.
    -->
    <AttributeDefinition id="uid" xsi:type="PrincipalName">
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false" />
    </AttributeDefinition>

    <!--
    In the rest of the world, the email address is the standard identifier,
    despite the problems with that practice. Consider making the EPPN
    value the same as your official email addresses whenever possible.
    -->
    <AttributeDefinition id="mail" xsi:type="Template">
        <InputAttributeDefinition ref="uid" />
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
        <Template>
          <![CDATA[
               ${uid}@example.org
          ]]>
        </Template>
        <SourceAttribute>uid</SourceAttribute>
    </AttributeDefinition>

    <!--
    This is an example of an attribute sourced from a data connector.
    -->
    <AttributeDefinition id="eduPersonScopedAffiliation" xsi:type="Scoped" scope="%{idp.scope}">
        <InputDataConnector ref="staticAttributes" attributeNames="affiliation" />
        <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" friendlyName="eduPersonScopedAffiliation" encodeType="false" />
    </AttributeDefinition>


    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <DataConnector id="staticAttributes" xsi:type="Static">
        <Attribute id="affiliation">
            <Value>member</Value>
        </Attribute>
    </DataConnector>

</AttributeResolver>

Reference

Formally, this is the configuration of the "AttributeResolver" service.  By default one file, attribute-resolver.xml, defines the attributes to be resolved. Multiple files can be specified by editing the bean referred to by the property idp.service.attribute.resolver.resources (default value shibboleth.AttributeResolverResources in the services.xml file) or changing the property to a different bean name.

Properties

The attribute-resolver.xml file can also use property replacement to externalize particular settings such as passwords. By default, these properties are defined in the idp.properties file, or you may define your own property files via the idp.additionalProperties setting. See the SpringConfiguration topic for more on property syntax.

The properties which affect the resolution process are names starting with idp.service.attribute.resolver as described here.

Attributes

The top level <AttributeResolver> element has one attribute 'id' which is used purely for logging purposes.

Child Elements

NameCardinalityDescription

<DataConnector>

anyDefines connections to sources of data which provide input to attribute definitions. These data sources are usually external (databases or attribute stores). It is also now possible when desired to directly export data from a connector without layering attribute definitions on top.

<AttributeDefinition>

anyAllows more precise formatting and transformations of input data into single attributes, as well as pre-V4 support for attaching encoders and other descriptive characteristics. Many use cases can now be handled without attribute definitions.
  • No labels