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 terminoly, 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