IDP proxing for vendors non-DS/Wayf capabilities

[Jehan PROCACCIA]

thanks Nate,

I understand the limitation of such a configuration. SLO doesn't matter, we don't use it anyway in other context .
and appearing to the SP as a single Entity , is actually what we want to. It's just our group of schools which happens to have their own sovereignty by administering their own IDPs that put us in such a situation regarding that SP that doesn't provide DS/WAYF . So appear to it as the signle IDP-proxy would be actually a feature as we would not have to modify each school's IDP to match that SP specificities (no-encrypt, persistent nameID, specific attributes ...) 

Back to my previous mail, can you tell me if I well interpreted the doc by associating 
1) "Original IdP EntityID: https://idp.example.ac.uk/entity" as beeing the IDP-proxy that will act as a SP to schools IDPs, so add to its metadata the <SPSSODescriptor .. elements ? 
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) 
1) and 2) are in our same federation, so they share all IDP+SP metadata (+ the IDP-proxy ones) 

If this configuration is not well proven and easy to implement, perhaps I'll have more chance with the 2nd option:
=> present the vendor SP only One IDP that has access to each schools end users referentials (ldap) 
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories

Thanks

----- Mail original -----
De: "Nate Klingenstein" <ndk at signet.id>
À: "users" <users at shibboleth.net>
Envoyé: Lundi 1 Février 2021 22:53:18
Objet: RE: IDP proxing for vendors non-DS/Wayf capabilities

> In other cases, it can be a massive problem, as everything appears to the proxy as just a standard authentication request from one monolithic entityID with no cues beyond that.

And, similarly, the end SP only sees assertions as coming from a single IdP,  In all cases, attributes are your lifeline, they're not going to be able to check scopes but you are, and logout is going to be an even bigger hairball than it usually is, as the proxying IdP only counts itself as a recipient of an assertion and AFAIK does not propagate logout requests received from the end SP back to the proxied IdP.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net