Apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure

Thu Mar 31 12:48:19 EDT 2016

I write to understand apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure. Perhaps I could help revise the documentation.
(I would also like to resolve why Azure is rejecting the SAML assertions my Shibboleth IDP is sending, although these are properly formed according to "Use a SAML 2.0 identity provider to implement single sign-on" in the section titled "Sample SAML Request and Response Messages," at  https://msdn.microsoft.com/en-us/library/azure/dn641269.aspx)
***

In https://wiki.shibboleth.net/confluence/display/IDP30/Office+365  concerning the configuration of conf/attribute-resolver.xml (section 4), we read

"Another attribute definition is typically required in order to send the Azure ImmutableID in the SAML Subject.  The ImmutableID attribute is site dependent, but most frequently maps to the "objectGuid" in Active Directory."

There appears to be no explicit mapping of ImmutableID-this identifier occurs only in the remarks at section 4  in https://wiki.shibboleth.net/confluence/display/IDP30/Office+365.
The example at 4 shows the identifier "uMemphisAdObjectGuid" both as the attribute id and the source within a directory. [In my implementation, I follow http://idmoim.blogspot.com/2015/02/office-365-integrating-with-shibboleth.html, in which the id is ImmutableID and the source is objectGUID. My data connector has the line
<dc:LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>
to ensure that the objectGUID is Base64 encoded-omit it and the objectGUID is transmitted in binary.  This seems to be the intention of the parenthetical remark concerning encoding in the comment ""   at section 4.
Note also that the attribute 'NameID' occurs for the first time in this comment-its relation to 'ImmutableID' is unclear.  Incidentally, Microsoft's documentation at https://technet.microsoft.com/en-us/library/jj205463#BKMK_1 omits the xml namespace identifier 'dc' in 'dc:LDAPProperty'. ]
It's the NameID value that seems confusing to me, since this appears to have two sources: attribute-resolver.xml, and saml-nameid.xml together with saml.nameid-properties.
***

Our attribute resolver uses the Active Directory object source attribute objectGUID and renames it as ImmutableID.
In saml-nameid.xml in my implementation, the ImmutableID is used to produce a NameID, and this is passed to the SAML assertion to Microsoft (I don't pretend to understand the mechanism, but this is what my firefox SAML trace reports). The relevant code from saml-nameid.xml is here:

<!-- Microsoft requires a custom Persistent ID Generator that sends the AD GUID -->
   <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
        p:attributeSourceIds="#{ {'ImmutableID'} }">
    <property name="activationCondition">
        <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{'urn:federation:MicrosoftOnline'}}" />
     </property>
  </bean>

However, there are properties in same-named.properties (not mentioned at https://wiki.shibboleth.net/confluence/display/IDP30/Office+365) that, in our case, take objectGUID and produce a hashed value based on a salt.

What is the difference between this computed value and the ImmutableID? Why does the unhashed base64 value of objectGUID appear as NameID in the SAML assertion? What happened to the hashed value set in saml-namid.xml? Where is it used? Which should be used so that logins will work?
[I could send the SAML assertions.]

***

The Shibboleth wiki page PersistentNameIDGenerationConfiguration<https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration> at
https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration,  which raises more questions than it answers; advises against using objectGUID for a persistent NameID (in case the AD changes). See the highlighted text below.
*         idp.persistentId.sourceAttribute
*         A list of attributes from which to derive a "source" key for the subject. The key is used as the hash input, and should be a very stable value for each subject and must never be reassigned later to a different subject. This should be a permanent serial number associated by an IDMS to each account, and not a name-based identifier like a login ID or email address. It should also be technology-neutral. Using a GUID generated by an Active DIrectory is a very bad choice that will lead to problems if you ever change directories.

*         We do have an alternative to objectGUID (an employeeID that stays with the subject, as opposed to some specific object representing the subject in a particular AD), but it is fair to say there is some tension between this recommendation and the remarks in section 4 of https://wiki.shibboleth.net/confluence/display/IDP30/Office+365.
[For now, let's stick with objectGUID; whatever is supposed to be the source of NameID will still be subject to the same questions and considerations, independently of whether an identifier tracks a subject as opposed to a particular object representation of a subject in some specific directory.]
*         Syntactically, how is the list represented? What semantic and syntactic relations, if any, does idp.persistentId.sourceAttribute in saml-nameid.properties have to the line
p:attributeSourceIds="#{ {'ImmutableID'} }"
in saml-named.xml? The comment in saml-nameid.properties states
"# For computed IDs, set a source attribute and a secret salt:" which seems to indicate that the argument is a single attribute and not a list.

Finally, the property  idp.persistentId.useUnfilteredAttributes, which is defaulted to the value true, according to the comment in saml-nameid.properties. This setting would appear to bypass the filtering in section 5 of  https://wiki.shibboleth.net/confluence/display/IDP30/Office+365 concerning the configuration of attribute-filter.xml.
(The example there switches to a version of the syntax prior to the version of my implementation, which is 3.2.1. In the example at section 5, the syntax xsi:type="basic:AttributeRequesterString" becomes xsi:type="Requester", following https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterLegacyNameSpaceMapping. This is not an issue, however.)

Thanks,

Florian Lengyel
CUNY Computing and Information Services
395 Hudson Street, 6-247, New York, NY 10014
646 664-2370, Florian.Lengyel at cuny.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160331/cb9a8a81/attachment-0001.html>