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 :

• https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP
• https://wiki.shibboleth.net/confluence/display/IDP4/SAMLAuthnConfiguration

Matching above doc terminology, here is how we interpreted it:

1. “Original IdP EntityID: https://idp.example.ac.uk/entity” beeing the IDP-proxy that will act as a SP to schools IDPs, so declare its metadata the <SPSSODescriptor .. element to act as a SP in the internal federation
2. “Upstream IdP EntityID: https://upstream.idp/entity” beeing the actual school IDP where nothing is changed, all configuration regarding : SAML flow, attribute-filter, subject canonicalisation beeing done in 1

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>

regarding our vendor SP , we present the traditional installed based IDP metadata with the IDPs SSO bindings endpoints (metadata/idp-metadata.xml)

<EntityDescriptor  xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" xmlns:req-attr="urn:oasis:names:tc:SAML:protocol:ext:req-attr" entityID="https://idproxy.domain.fr/idp/shibboleth">

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
....
 <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://idproxy.domain.fr/idp/profile/Shibboleth/SSO"/>
        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" req-attr:supportsRequestedAttributes="true" Location="https://idproxy.domain.fr/idp/profile/SAML2/Redirect/SSO"/>
        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" req-attr:supportsRequestedAttributes="true" Location="https://idproxy.domain.fr/idp/profile/SAML2/POST/SSO"/>
        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" req-attr:supportsRequestedAttributes="true" Location="https://idproxy.domain.fr/idp/profile/SAML2/POST-SimpleSign/SSO"/>
   </IDPSSODescriptor>
...
    <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idproxy.domain.fr:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>

    </AttributeAuthorityDescriptor>

</EntityDescriptor>
       

Beware , in a traditional IDP role, the load of metadata providers (in conf/metadata-providers.xml) usually comes with a “EntityRoleWhiteList” that loads only SPs from the Federation Metadatas, but here we act as a SP so we really need to load IDPs roles !

<!-- comment Role to load only SP in this context 
 <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter> -->