Closed joostd closed 9 years ago
Could you supply a (preferably public) URL for testing?
curl -s http://mds.edugain.org/ | xpath '//md:EntityDescriptor[@entityID="https://aai.unifr.ch/idp/shibboleth"]'
Tested this and https://aai.unifr.ch/idp/shibboleth
has 4 SSO endpoints, 0 which is shibboleth, 1 and 2 are saml2 and a custom binding type 3.
Janus will now import binding 1 and 2 but renumber them to 0 and 1.
See also: https://github.com/OpenConext/OpenConext-engineblock/issues/106
when a new IDP is created in Janus's Connection tab, a default SingleSignOnService entry with index 0 is created with a Binding of HTTP-Redirect.
If SAML 2.0 metadata is subsequently imported that contains a Binding that Janus (presumably) doesn't know about, for instance:
the corresponding Location will be stored, but not the Binding. This will result in an inconsistent entry with the following values:
SingleSignOnService:0:Location=https://idp.example.org/idp/profile/Shibboleth/SSO SingleSignOnService:0:Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
This will trigger an error at the IDP whenever a SAML 2.0 authentication request is received, because a SAML 2.0 request is sent to a SAML 1.1 endpoint.
These endpoints are typically published by Shibboleth IDPs