How does ShibbolethSP match SAML assertion Issuer and SSO entityID?
Martinet Renaud
renaud.martinet at horoquartz.fr
Tue Jan 9 10:23:47 EST 2018
Hi,
I ran into a problem that I'm not sure is a bug with ShibbolethSP or just
normal behavior but a misunderstanding of the SAMLv2 specs on my
part.
I thought I would first run this by you before eventually submitting a bug.
We use ShibbolethSP 2.6.0 on Debian Stretch and our partner uses ADFS.
In some cases, our partner sends back SAML assertions with an Issuer
element slightly different than the entityID we have registered for
him in //SPConfig/ApplicationDefaults/Sessions/SSO/@entityID in
/etc/shibboleth/shibboleth2.xml
The subdomain part is uppercase instead of lowercase in
//xml/samlp:Response/Issuer in the SAML assertion.
Eg. https://IDP.prod.example.com/adfs/services/trust instead of
https://idp.prod.example.com/adfs/services/trust
In this case, it seems that Shibd performs a case sensitive
comparison and therefore can't find any metadata corresponding
to the entityID https://IDP.prod.example.com/adfs/services/trust.
I think this is strange since it looks like a URI and I expected it to be
handled like a URI: with the hostname being case insensitive.
I found a thread [1], although not related to ShibbolethSP, that was
talking about case sensitivity in entityID values such as Issuer.
It seems entityID itself is defined as anyURI in the specs, which is not
case sensitive.
But saml:Issuer is defined as a string, which is case sensitive, in the
SAML assertion schema.
Also the saml-core-2.0-os spec [2] says in section 2.2.5 that if no
Format attribute is present then the format
urn:oasis:names:tc:SAML:2.0:nameid-format:entity is assumed.
This format is defined in section 8.3.6 as a URI which is case insensitive.
In the end, I don't know which definition ShibbolethSP uses and
therefore what is the expected behavior in this case.
I had a look at the wiki, the bug tracker and the mailing list archive but
didn't find anything relevant. Could you shed some light on this?
Thanks!
Renaud.
[1] https://social.msdn.microsoft.com/Forums/azure/en-US/25c60c20-0674-4bc0-822b-fff1e2b7f1ad/service-namespace-inconsistent-when-using-saml2-lower-caseupper-case?forum=WindowsAzureAD
[2] http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
More information about the users
mailing list