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

[Michael A Grady]

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

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>

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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://shibboleth.net/pipermail/users/attachments/20160331/2d6d6cee/attachment.sig>