TABLE OF CONTENTS

• Attribute Resolver
• About this guide
• The process
• V3 attribute-resolver.xml file
• AAF Core and Optional attributes
• Scripted attributes
• Local Attributes
• Data Connectors

Attribute Resolver

Many of the changes to the Shibboleth IdP occurred in the attribute-resolver.xml configuration file that make this configuration less cluttered and simpler to understand. 

First the is the removal of much of the attribute details into the attributes area. 

Second is a change to how the source values for each attribute are referenced. 

Third is the introduction of two new identity attribute, the Subject ID and the PairWise ID. These new attributes are intended to remove the need to the eduPersonTargetedID (which has been deprecated for some time now). There may also be an opportunity to deprecate the auEduPersonSharedToken over the next few years. 

There are other minor changes to the attribute resolver most of which won’t impact a standard deployment.

About this guide

This guide is intended to help you transform your existing Shibboleth v3 attribute-resolver.xml file into a much smaller Shibboleth v4 attribute-resolver.xml. By converting to the version v4 layout you will future proof you IdP as the older layout is removed in future versions. It will also make the configuration simpler to read and maintain.

The process

There is no easy way to do this, you need to review each attribute’s configuration one-by-one to ensure the conversion of each attribute is correct, that it generates the same value on your old IdP as it does for your new IdP. We have however tried to make this process simper by providing a standard migration for all AAF Core and many of the optional attributes for you. You still need to check each, and you will need to migration your own local attributes.

V3 attribute-resolver.xml file

Your V3 attribute-resolver.xml have been copied in the v3-export area, so it should be available on your new server in the directory V3-export/config

Start with this file and work your way through each AttributeDefinition and DataConnector in turn.

AAF Core and Optional attributes

New version of all AAF Core and Optional attributes have been converted. You must either verify that the source attributes are the same or update as required. A simple example follows;

Attribute definition for givenName version 3

  <resolver:AttributeDefinition xsi:type="ad:Simple" id="givenName"
                                sourceAttributeID="givenName">
    <resolver:Dependency ref="ldap" />
    <ressolver:DisplayName xml:lang="en">Given name</DisplayName>
    <resolver:DisplayDescription xml:lang="en">Person's given or first name.</DisplayDescription>
    <resolver:AttributeEncoder xsi:type="enc:SAML1String" 
              name="urn:mace:dir:attribute-def:givenName" encodeType="false" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2String" 
              name="urn:oid:2.5.4.42" friendlyName="givenName" encodeType="false" />
  </resolver:AttributeDefinition>

The same definition for version 4

    <!-- givenName -->
    <AttributeDefinition id="givenName" xsi:type="Simple">
       <InputDataConnector ref="ldap" attributeNames="givenName" />
    </AttributeDefinition>

As you can see most of the details have been moved to the attributes directory, the name space detail has been removed and how the source attributes are references has changed.

Other changes have also occurred, you will see some changes to identifier names. As these names are internal to the IdP there is no risk of changes to the attribute names sent from the IdP to SPs. The attribute identifiers that have changes follow

Note: Unless your old IdP uses a different attribute or method to generate the values for these attributes, there will be no need to change these attributes.

Scripted attributes

A number of attributes utilize scripts to process source attributes to produce user attribute values. The eduPersonAffiliation is such an attribute. In general, the v3 scripts should work in V4. You should check the idp-process.log or idp-warn.log file after you re-start your IdP looking for IdP deprecation warnings that relates to your scripts.

Note: The warning message will inform you of the change the should remedy the deprecation issue.

Local Attributes

You may have defined a number of local attributes for use with your bi-lateral services to as source values to other attributes. To convert these attributes, you MUST change how the attribute sources it’s vales using either a InputAttributeDefinition or InputDataConnector. 

Next create an attribute dictionary entry for your attribute. This will result in a .json file that resides in the directory assets/[SERVER-NAME]/idp/conf/attributes/custom. You will find a number of examples in this directory that you can use as a template. The file holds information about the attribute used when encoding for sending to the SP. This information can then be removed from the attributes definition in the attribute-filter.xml file.

Data Connectors

The attribute-resolver.xml file contains a number of data-connectors that links source attributes to their data source. This includes your local LDAP or Active Directory, a local database for some of the identity attributes and statically defined attribute values held within the attribute-resolver.xml file. Only minor changes have occurred to the data connectors. The four data connects suppiled in the new attribute-resolver.xml should be fine.

• Static Data connectors - For values that are the same for all users

• LDAP data connector - Connects to your LDAP or Active directory for attributes

• StoredID Data connector - Generate and retrieve the eduPersonTargetedID

• Shared Token Data connector - Generates or retrieves the auEduPersonSharedToken