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

Wed Apr 13 14:56:15 EDT 2016

I can't be grateful enough with every person who contributed in this thread. Thanks to you I was able to get Shibboleth IdP 3.2 up and running against Azure Active Directory (Office 365). The wiki page was absolutely misleading. I'll be creating a new one with the correct procedure if you don't mind.

Regards,
Carlos

Carlos Milán Figueredo | HispaMSX System Operator |   http://www.hispamsx.org | |  telnet://bbs.hispamsx.org

> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Florian
> Lengyel
> Sent: jueves, 31 de marzo de 2016 22:23
> 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
> 
> 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/PersistentNameIDGenerati
> onConfiguration,  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
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net