This is an old revision of the document!
It happens that SP vendors don't provide Discocery Service/WAYF SP initiated SSO (has we are used in academic/research ecosystem) so they ask us to register as many IDP as we have universities/school in our group of internals federated IDPs .
to circonvent that constraint, we decided to expose and register only one IDP (one to one) with those vendors. this IDP will act as a proxy between the vendor SP and internals IDPs . that IDP “in the middle” will act as a IDP for the SP and as a SP regarding internals IDPs .
reference :
Matching above doc terminology, here is how we interpreted it:
The idea is to present one set of metadata to our internal federation/IdP's and one set of metadata to the vendor SP, which both happened to use the same entityID (our IDPproxy) . We would not be publishing both versions in the internal federation metadata. The federation never needs to know, technically, that we're a proxy. Our IDPproxy just look like another service.
act as a SP in internal Federation, metadata looks like :
<md:EntityDescriptor ID=“_5b39720f724ef5a082af7739d48bf4da3c5523d5” entityID=“https://idproxy.domain.fr/idp/shibboleth” xmlns:md=“urn:oasis:names:tc:SAML:2.0:metadata”>
<md:SPSSODescriptor protocolSupportEnumeration=“urn:oasis:names:tc:SAML:2.0:protocol”>
<md:KeyDescriptor use="signing"> ... <ds:X509Certificate> ...
<md:AssertionConsumerService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=“https://idproxy.domain.fr/idp/profile/Authn/SAML2/POST/SSO” index=“0”/>
</md:SPSSODescriptor>
</code>