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

Thu Mar 31 16:23:10 EDT 2016

Thanks -- I'd like to help update the wiki (once I get my configuration to work, which sends what Microsoft seems to expect.)

One thing that could be removed from https://wiki.shibboleth.net/confluence/display/IDP30/Office+365 is the reference in section 4 of  to "ImmutableID." Apparently this is a reference to the base64 representation of objectGUID within Azure's cloud under some directory synching operation. If this term does have some technical significance, it could be mentioned specifically; otherwise it should be removed.

Some of the syntax is from V2; this could be updated. Also, a specific statements referring to the "actual documentation" within the wiki at each point in the configuration where  MS requires something that contradicts SAML standard would be helpful. I can write this--I've been working on Shibboleth for a week.

I'll say more later--I'm preoccupied with another matter.

Thanks for the warm welcome,

Florian
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Walter Forbes Hoehn (wassa)
Sent: Thursday, March 31, 2016 3:32 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure

Florian,

As Scott pointed out in another reply, the Wiki page you are referencing isn’t really part of the “official” project documentation. There was a “Commercial Interop” section in the IdP V2 Wiki space where deployers could add helpful notes related to difficult integrations. I copied that section over to the V3 space and added this page because I found the Office365 integration to be particularly onerous… requiring anti-standard configuration and being very difficult to debug, except through trial-and-error. The idea wasn’t for the page to be an exhaustive reference, but rather a quick working example configuration to help get others past some of the pain that I went through.

I looked over the page very quickly and don’t find anything to be internally contradictory. Having said that, I’m happy to help make it better, or you can edit it yourself. Honestly, I was a bit confused by some of your points below. Perhaps we could start with a particular item that you find to be unclear? As Peter and Scott have both pointed out, the configuration recommended in this page contradicts the SAML standard, but it appears to me to be what is required by MS.

-WFH

> On Mar 31, 2016, at 11:48 AM, Florian Lengyel <Florian.Lengyel at cuny.edu> wrote:
> 
> 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 “<!-- Needed Office365 Integration. Used for NameID value. (No encoder necessary) -->”   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 athttps://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 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 syntaxxsi:type="basic:AttributeRequesterString" becomes 
> xsi:type="Requester", 
> followinghttps://wiki.shibboleth.net/confluence/display/IDP30/Attribut
> eFilterLegacyNameSpaceMapping. 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
>  
> --
> To unsubscribe from this list send an email to 
> users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net