IDP proxing for vendors non-DS/Wayf capabilities

Mon Feb 1 21:39:21 UTC 2021

I take the challenge to use IDP-proxing in order to allow vendor SP 
(DocuSign) to take the IDP-proxy as the only IDP registered, then that 
idp-proxy would request our group of schools internal IDPs  (don't know 
yet how it will pass over each ones ..., I just test with one proxy and 
one IDP "backend" ) .
I followed 
https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP
but I am wondering if I well understood the roles of differrent parties 
in that doc

  * /1) Original IdP EntityID: //|https://idp.example.ac.uk/entity #
    |/
  * /2) Upstream IdP EntityID: //|https://upstream.idp/entity|/
  * /3) Joining attribute (common to both services): //|uid|//(unscoped
    username)/

I took 1) as the IDP-Proxy (frontend to all others current IDPs) and 2) 
as actual school's IDP, is this correct interpretation ?

While testing on a local SP  , I took 1) (IDP-proxy ) as the IDP to 
authenticate to, then expected to be redirected to 2)

But IDP-proxy logs (in debug) shows an INFO message about "No metadata 
in role ..." (in bold below) , that makes me wonder if I did correctly 
recorded the |||<||SPSSODescriptor |:
element in the correct IDP metadata (here I did it in 1) the proxy , not 
2) !)

/2021-02-01 21:54:01,286 - - DEBUG 
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:369] - Profile 
Action SelectAuthenticationFlow: Selecting inactive authentication flow 
authn/SAML//
//2021-02-01 21:54:01,450 - - DEBUG 
[net.shibboleth.idp.saml.session.impl.PrepareInboundMessageContext:143] 
- Profile Action PrepareInboundMessageContext: Initialized inbound 
context for message to https://idpschool1.domain.fr/idp/shibboleth//
//2021-02-01 21:54:01,457 -  - INFO 
[org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:167] - 
Message Handler: //*No metadata returned for 
https://idpschool1.domain.fr/idp/shibboleth in role 
{urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor with protocol 
urn:oasis:names:tc:SAML:2.0:protocol*/
/
/
/2021-02-01 21:54:01,467 -  - WARN 
[net.shibboleth.idp.profile.impl.SelectProfileConfiguration:118] - 
*Profile Action SelectProfileConfiguration: Profile 
http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for 
RP configuration shibboleth.UnverifiedRelyingParty (RPID 
https://idpschool1.domain.fr/idp/shibboleth)*//
//
/
/2021-02-01 21:54:01,486 - - INFO 
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:142] - Profile 
Action SelectAuthenticationFlow:*Moving incomplete flow authn/SAML to 
intermediate set*//
/
/
/
/2021-02-01 21:54:01,487 - - INFO 
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:316] - Profile 
Action SelectAuthenticationFlow: No potential flows left to choose from, 
authentication failed//
//
/
/2021-02-01 21:54:01,673 -  - INFO [Shibboleth-Audit.SSO:282] - 
2021-02-01T20:54:00.489203Z,2021-02-01T20:54:01.444210Z|2021-02-01T20:54:01.672917Z||https://testsp.domain.fr/sp||||||||false||Redirect|POST||Requester|urn:oasis:names:tc:SAML:2.0:status:*AuthnFailed*|/

thanks to help me debug that touchy configuration .

Le 29/01/2021 à 17:23, Jehan PROCACCIA a écrit :
> Hello,
> I recently echange here about my experiences on shibboleth IDP4 with 
> DocuSign SP (cf my howto: 
> https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign 
> <https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign>) 
>
> I noticed that usually SP vendors don't provide Discocery Service/WAYF 
> SP initiated SSO  (has we are used in academic/reserch ecosystem)
> so they ask us to register as many IDP as we have universities/school 
> in ou group of federated IDPs .
> I came accross those pages:
>
> https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP
> https://spaces.at.internet2.edu/display/GS/SAMLIdPProxy 
> <https://spaces.at.internet2.edu/display/GS/SAMLIdPProxy> (quite old, 
> I guess I should stick with the 1rst one ...)
>
> Do you think that's a right choice to circumvent the lack of DS/WAYF , 
> by registering only One proxied IDP to the vendor SP and let that 
> proxied IDP do the job to delegate authN to our locals federation end 
> users IDPs ?
>
> Or would it be better/simpler to present to 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> 
> (I guess it works also in IDPv4)
> or
> https://github.com/ConsortiumGARR/idem-tutorials/blob/master/idem-fedops/HOWTO-Shibboleth/Solutions/HOWTO%20Configure%20a%20Shibboleth%20IdP%20v3.2.1%20to%20authenticate%20Users%20existing%20on%20different%20LDAP%20Servers.md
>
> I'am at the starting point to go into the direction of Proxy IDP or a 
> single IDP with multiple ldap directories, which would be a better 
> choice ?
>
> thanks for you advice .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210201/773da1ba/attachment.htm>