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

[Florian Lengyel]

Thanks for this -- that's pretty close to what I've done. (I'm new to this--the documentation seems to contradict itself.) I'll check and get back to the list.

-F

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Michael A Grady
Sent: Thursday, March 31, 2016 2: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


> 
> They aren't related in any way. idp.persistentId.sourceAttribute is used to configure the hash seed for a computed persistentID. If you were to create your own configuration that leveraged that property for a separate purpose, that would be a local choice of course.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


I did not test whether Microsoft would accept a different format for the NameID, because I was helping someone migrate existing config, and I didn't have time to explore (nor a test O365 domain in which to do that testing) whether the format could be changed from what they already were using. But as Scott noted on a different thread earlier today about the Persistent NameID format, the NameID Microsoft wants is NOT a valid SAMLv2 Persistent NameID, even though that is what the below is going to say it is.

OK that is a technical helpful remark, without any moralizing. Thank you.

The following works:

resolver:

   <!-- Begin Office 365 Attributes
         Note: Office 365 prefers to map the objectGUID for the immutable ID on a person
    -->
    <resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="objectGUID">
       <resolver:Dependency ref="campusActiveDirectory" />
    </resolver:AttributeDefinition>

and make sure on the AD/LDAP connector:

    <dc:LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

Don't touch saml-namid,properties unless you have other reasons to. In saml-nameid.xml, you then add:

	    <!-- 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>

Where specifically is this added? This is almost identical to what I have, incidentally.

And you "limit the damage of that invalid persistent nameid" by having that condition to only create that NameID for the SP it is needed for. You also, amongst a variety of special Relying Party config for them, need to tell it to use that format by adding a:

  p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"


Has anyone tested whether O365 actually checks the format and cares?

I'll try it--another group here has a ticket open with Microsoft.


--
Michael A. Grady
IAM Architect, Unicon, Inc.


Many thanks,

FL