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

Florian Lengyel Florian.Lengyel at cuny.edu
Tue Apr 5 11:59:47 EDT 2016


It turns out that what Azure calls its ImmutableID (corresponding to the custom NameID attribute defined for Microsoft Online  in saml-nameid.xml) was, in our case, employeeID, not objectGUID. [Incidentally, I of course agree with the official Shibboleth documentation  that using the objectGUID "generated by an Active Directory is a very bad choice"  https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration ]

After renaming the source attribute in attribute-resolver.xml to employeeID (and changing ldap.properties appropriately), our test user account was able to login to Office 365. We seem to have no problems with the ECP configuration.

Regarding your question, omitting the SHA1 security configuration override from the relying party override for Microsoft in relying-party.xml made no difference--I'm inclined to keep it however (thank you for this). The relevant portion of the SAML response we send to https://login.microsoftonline.com/login.srf shows that the correct signature block requirements are present (following https://msdn.microsoft.com/en-us/library/azure/dn641269.aspx):

<ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                <ds:Reference URI="...">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                            <ec:InclusiveNamespaces PrefixList="xsd"
                                                    xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                                                    />
                        </ds:Transform>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <ds:DigestValue>...</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>

If the opportunity to modify the wiki is available, I am willing to do this. The technical considerations are limited enough to be able to state clearly and concisely, without  unnecessary disclaimers.

And finally, thanks to the list for helpful comments and suggestions.

-FL

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Michael A Grady
Sent: Thursday, March 31, 2016 9:18 PM

...


So I didn't earlier list the full Relying Party overrides, from the default v3 settings, for O365. Mostly because I can't say for 100% certain that all of these overrides are necessary. I was working with a client that had an existing working config with O365 (including using ECP), and no way to test the v3 settings (no O365 test domain) without impacting Production, so the safest bet to make was to match the settings they had in their v2 config. It's possible that your error could stem from not matching one of these, including whether the SHA1 (default in v2) or SHA256 signing algorithm (default in v3) is used. (There are web pages that suggest that O365 still requires SHA1.) So you could try these (if you don't already have them), and see if any help. And maybe you also have the opportunity to test exactly which of these are actually really required today.


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



More information about the users mailing list