Advice on planned IdP configuration changes associated with implementing SAML 2

[Julian Williams]

Hi,

First up I should say that I have fairly recently taken over the administration of our Shibboleth IdP and there is a significant amount of background history to its configuration (some of which I have still to understand) as it was one of the first IdPs in the UK Federation.

We are planning to go ahead with an update to our IdP's metadata next week to include the SAML2 profiles (currently we are only publishing the 1.1 profiles). As you can appreciate this is long overdue but the last time it was attempted here (2011) we had problems with a number of SPs/applications and had to back-out the change. The problems we had last time seem to be associated with the eduPersonTargetedID not being provided in SAML2 connections. 

Unfortunately further progress has been stalled until recently because it's been difficult to arrange testing of other 3rd party applications against our test IdP. However after some more thorough local testing we believe that we have identified the problem with our IdP configuration which mostly boils down to an omission in the attribute-filter.xml. This seems fairly obvious now but was being clouded by some complexity in the range of eduPersonTargetedID variants that were specified in our attribute-resolver.xml.

A summary of the pertinent bits in our *current* attribute-resolver.xml are below:

########################################################
    <!-- eduPersonTargetedID (old) -->
    <resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
        scope="ox.ac.uk" sourceAttributeID="computedID">
        <resolver:Dependency ref="computedID" />

        <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:mace:dir:attribute-def:eduPersonTargetedID" />
    </resolver:AttributeDefinition>

    <!-- persistent ID (transition) -->
    <resolver:AttributeDefinition id="persistentID" xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
        nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" sourceAttributeID="computedID">
        <resolver:Dependency ref="computedID" />

        <resolver:AttributeEncoder xsi:type="SAML1XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />
    </resolver:AttributeDefinition>

    <!-- eduPersonTargetedID (new) -->
    <resolver:AttributeDefinition id="eduPersonTargetedIDNew" xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
        nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" sourceAttributeID="computedID">
        <resolver:Dependency ref="computedID" />

        <resolver:AttributeEncoder xsi:type="SAML1XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />

        <resolver:AttributeEncoder xsi:type="SAML2XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />
    </resolver:AttributeDefinition>
########################################################

We have realised now that the new type of eduPersonTargetedID (currently id="eduPersonTargetedIDNew") wasn't being included in the default release policy in attribute-filter.xml so that was the main reason why there wasn't any eduPersonTargetedID type attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) released once SAML2 connections were being used. 

Confusing this slightly is the fact that the attribute definition for id="persistentID" is providing the new type of eduPersonTargetedID but only for SAML1 connections (because no 'SAML2XMLObject' encoding was configured). It seems now that this definition is redundant as the equivalent attribute is provided in the 'SAML1XMLObject' encoding for the id="eduPersonTargetedIDNew". No one here can remember why the attribute definition for id="persistentID" was originally included but it seems likely that it was something that was introduced with the old version of IdP (1.3 I think) and was copied across when we upgraded to 2 in early 2011.

So what we plan to do is change the attribute-resolver.xml to fix these things and better match the UK Federation's reference at <http://www.ukfederation.org.uk/content/Documents/Setup2IdP>

So the new resolver config will look like that below:

########################################################
    <!-- eduPersonTargetedID (old) -->
    <resolver:AttributeDefinition id="eduPersonTargetedID.old" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
        scope="ox.ac.uk" sourceAttributeID="computedID">
        <resolver:Dependency ref="computedID" />

        <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:mace:dir:attribute-def:eduPersonTargetedID" />
    </resolver:AttributeDefinition>

    <!-- eduPersonTargetedID (new) -->
    <resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
        nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" sourceAttributeID="computedID">
        <resolver:Dependency ref="computedID" />

        <resolver:AttributeEncoder xsi:type="SAML1XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />

        <resolver:AttributeEncoder xsi:type="SAML2XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />
    </resolver:AttributeDefinition>
########################################################

And this time we will make sure that both eduPersonTargetedID.old and eduPersonTargetedID are included in the default policy in attribute-filter.xml !

I have tested this on our test IdP against a range of test SPs that the UK Federation provides at <https://test.ukfederation.org.uk/index.html> and all the tests behave as I'd expect with:
* SAML1 requests getting both the old 'scoped' eduPersonTargetedID (urn:mace:dir:attribute-def:eduPersonTargetedID) and the new eduPersonTargetedID (urn:oid:1.3.6.1.4.1.5923.1.1.1.10).
* SAML2 requests getting just the new eduPersonTargetedID (urn:oid:1.3.6.1.4.1.5923.1.1.1.10).

What I'd like to check with you specifically is:

1. That there is no need to include a SAML2 encoding for the old type of scoped eduPersonTargetedID (urn:mace:dir:attribute-def:eduPersonTargetedID). >From what I have read it shouldn't be provided in a SAML2 request and SPs should be able to work without it provided they have the new type of eduPersonTargetedID. Or are there some instances where a 'legacy' SP/application might still have to get it?

2. The attribute definition that we currently have for id="persistentID" is indeed not required as the same attribute is provided by the SAML1XMLObject encoding of the new type of eduPersonTargetedID (urn:oid:1.3.6.1.4.1.5923.1.1.1.10)

Any help you feel you can give would be much appreciated.

Kind Regards,

Julian

--
Julian Williams (Identity and Access Management Developer)
Systems Development and Support, IT Services, University of Oxford