IDP proxing for vendors non-DS/Wayf capabilities

Tue Feb 2 14:27:06 UTC 2021

>> 1) "Original IdP EntityID: https://idp.example.ac.uk/entity <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 ? 

> Yes.  Your federation may have problems handling this or it may not.  But remember that your proxy is only being seen as an SP by the federation and schools' IdP's, and it's only being seen as an IdP by the end SP, so in the proxying case, two different metadata files with the same entityID may be the least confusing option most likely to successfully load in commercial or homegrown implementations.

As I understand I should create a dedicated  SP metadata for my IPD-proxy in regard to other school's IDP 
<EntityDescriptor ... <SPSSODescriptor ...AssertionConsumerService.. />  
but still have a IDP metadata ( <IDPSSODescriptor ...)  for that same IDP-proxy to be presented to the Vendor SP (DocuSign) 
as I am testing inside our local federation, I am afraid that having the same 2 EntityID names ;  entityID="https://idproxy.domain.fr/idp/shibboleth" (one for SP "side" and the other for IDP "side"  of the same entityID)  in the same aggregated federation medatadas xml file might generate problems => loading just one of the 2 instances (SP or IDP) , or worst, completly crash the federation metadata load from schools SPs en IDPs  .

So I will test with a SP that act as the vendor, loading only my IDProxy medatata, and leave others schools IDPS/SP to load the aggregated federation Metadatas which would contain IDProxy SP "side" of metadata. 

Correct me if necessary. 

Thanks . 

-----Original message-----
From: Jehan PROCACCIA
Sent: Monday, February 1 2021, 3:26 pm
To: users
Subject: Re: IDP proxing for vendors non-DS/Wayf capabilities

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 <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 <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)

=> 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 <https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories>

Thanks

----- Mail original -----
De: "Nate Klingenstein" <ndk at signet.id <mailto:ndk at signet.id>>
À: "users" <users at shibboleth.net <mailto: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 <https://www.signet.id>
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>

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

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