IDP proxing for vendors non-DS/Wayf capabilities

Mon Feb 1 21:45:31 UTC 2021

Jehan,

I can't say much about this because it's some work we've done for clients in the past, but remember the SP has either no or few ways to inform the proxy which organization it wants the users to originate from.  In some integrations, this may not be an issue, since you're relying on the data returned.  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.

Thanks for keeping us informed,
Nate.

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

https://www.signet.id

-----Original message-----
From: jehan Procaccia tem-tsp
Sent: Monday, February 1 2021, 2:39 pm
To: users
Subject: Re: IDP proxing for vendors non-DS/Wayf capabilities

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 <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 <https://idp.example.ac.uk/entity>
              #

        	2) Upstream IdP EntityID: https://upstream.idp/entity <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 <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 <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 <http://shibboleth.net/ns/profiles/saml2/sso/browser> is not
            available for RP configuration
            shibboleth.UnverifiedRelyingParty (RPID
            https://idpschool1.domain.fr/idp/shibboleth <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 <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://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 <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 .

--

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