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

[Florian Lengyel]

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott

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

>You certainly shouldn't use SHA1 unless you have to.
..

> -- Scott

While I agree with the sentiment,  it is silent on the technical question whether an explicit override 
of the default signing configuration is necessary in the relying party configuration for Microsoft O365. 
This is the question Michael A. Grady posed earlier.

The answer is no: the O365 metadata at
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
includes digest and signing method  extensions to specify SHA1: 

<Extensions>
<alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
</Extensions>

and the Shibboleth idp honors this. 
(Extension syntax is described here: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupport-v1.0-cs01.html#__RefHeading__5805_234507477)

No explicit override of the signing configuration (in relying-party.xml or elsewhere) is necessary or desirable, whether Microsoft upgrades its signing and digest algorithms from SHA1 and modifies its metadata accordingly--or not.


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