By Something I forgot to mention in my earlier post about getting Shibboleth working with Office365 was our need to tweak the config a bit beyond what the whitepaper instructs.
I was having a problem whereby the IdP was refusing to write a SAML assertion, I think just over ECP, because the NameID format it was trying to generate (urn:oasis:names:tc:SAML:2.0:nameid-format:transient) wasn’t supported. Annoyingly the Shibboleth logs from when I encountered the problem have cycled away so I can’t quote the exact error message.
Either way, with a bit of digging, I discovered this page (in Austrian/German) which gave me enough of a hint to try editing my <RelyingParty> tag for MicrosoftOnline to include:
nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
So my complete <RelyingParty> XML block is now:
<!-- Microsoft Windows Azure AD --> <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="__ENTITYID__" defaultSigningCredentialRef="IdPCredential" nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" > <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" signAssertions="conditional" encryptAssertions="never" encryptNameIds="never" /> <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="never" encryptNameIds="never"/> </rp:RelyingParty>