IDP proxing for vendors non-DS/Wayf capabilities

Tue Feb 2 15:15:11 UTC 2021

Jehan,

> I am afraid that having the same 2 EntityID names ;  entityID="https://idproxy.domain.fr/idp/shibboleth <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  

Right, but this also goes for the combination of the two.  It all depends on the software in use, the ways in which it is or isn't buggy, and whether it can handle the concept of an entity that serves both roles.

Assuming deployers in the federation aren't using MDQ ubiquitously, remember that when your federation is published to the federation, one entity with both IdP and SP capabilities would be included.  Some federation management software can't even handle doing such a thing itself(which means it doesn't work even in the MDQ scenario).  Some SP's or IdP's who are federation members may find their software to break abruptly if it parses metadata that contains both an IDPSSODescriptor and an SPSSODescriptor poorly, and many federations have no clue about what software is being deployed within them, so making a significant change like permitting entities that are both SP's and IdP's is a significant step for a federation to consider, just like you're thinking through now.

You definitely don't want to give two differing versions of the metadata for the same entityID provided to any provider or federation.  You would instead be presenting 1 set of metadata to the federation/IdP's and 1 set of metadata to the SP, which both happened to use the same entityID.  You would not be publishing both versions in the federation metadata.  The federation never needs to know, technically, that you're a proxy.  You just look like another service.  The rest is policy.

You could likely wire up the IdP to use different entityID's for the different facades if you really wanted to, but that's a lot of work for no real benefit other than moving the confusion from one spot to another, and a lot of this code is going to change in 4.1 anyway.

So, to put it more accurately, using this approach, you have 1 entityID and 2 metadata documents describing them, but you also don't have a conflict.  You have different metadata documents describing providers that you can interact with that happen to share a single entityID.  One of those metadata documents is for when that entityID is playing IdP, and one for when it's playing SP.  You give an appropriate IdP metadata document to the SP's that you're dealing with, and you give the appropriate SP metadata document to the IdP's that you're dealing with(e.g. the federation).  No different than any other metadata exchange except that the entityID is the same, but it's the same in such a way that it will not conflict, because there is no entity to which it acts as both an IdP and an SP until your use cases get *really* out there.

Hope this clarifies things,
Nate.

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

https://www.signet.id

-----Original message-----
From: Jehan PROCACCIA
Sent: Tuesday, February 2 2021, 7:27 am
To: users
Subject: Re: IDP proxing for vendors non-DS/Wayf capabilities

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

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> <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> <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> <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> <mailto:ndk at signet.id <mailto:ndk at signet.id>>>
À: "users" <users at shibboleth.net <mailto:users at shibboleth.net> <mailto: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> <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> <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> <mailto: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> <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> <mailto: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>

----- 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 23:42:30
Objet: RE: IDP proxing for vendors non-DS/Wayf capabilities
-- 
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>