Enforcing SAML2/transmission of persistentId for WAYF service?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Enforcing SAML2/transmission of persistentId for WAYF service?

Stefan Kombrink

Dear community,

 I've got a SP setup, where I require the persistentId, and I want to attach a discovery service.

As long as I define a single IdP as entityId I retrieve the persistentId during a session:

<SSO entityID="https://idp-test.rz.uni-ulm.de/idp/shibboleth">SAML2 SAML1</SSO>

SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:<a class="moz-txt-link-freetext" href="classes:PasswordProtectedTransport">classes:PasswordProtectedTransport

When I switch over to WAYF:

<SSO discoveryProtocol="WAYF" ECP="true" discoveryURL="https://wayf.aai.dfn.de/DFN-AAI-Test/wayf/www/WAYF.php">SAML2 SAML1</SSO>

I do not get the persistentId any longer. Furthermore, I can see the Session is using

SSO Protocol: urn:oasis:names:tc:SAML:1.1:protocol
Authentication Context Class: urn:oasis:names:tc:SAML:1.0:am:password

To me it seems as if the WAYF forces it to use SAML1, and that's why I do not obtain the entityID. Is that so?

Is there a discovery service I could use instead which will be SAML2 compatible and give me the persistentID?


thanks & best regards

Stefan

-- 
Kontaktdaten: https://portal.uni-ulm.de/ETB/ab/showPerson.html?pid=46110

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Enforcing SAML2/transmission of persistentId for WAYF service?

Stefan Kombrink

Okay, to answer my own question, I had to change the SSO into:

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://wayf.aai.dfn.de/DFN-AAI-Test/wayf">SAML2</SSO>

Now it uses SAML2 and I get an persistentId.

Stefan

Am 21.11.2019 um 08:24 schrieb Stefan Kombrink:

Dear community,

 I've got a SP setup, where I require the persistentId, and I want to attach a discovery service.

As long as I define a single IdP as entityId I retrieve the persistentId during a session:

<SSO entityID="https://idp-test.rz.uni-ulm.de/idp/shibboleth">SAML2 SAML1</SSO>

SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:<a class="moz-txt-link-freetext" href="classes:PasswordProtectedTransport" moz-do-not-send="true">classes:PasswordProtectedTransport

When I switch over to WAYF:

<SSO discoveryProtocol="WAYF" ECP="true" discoveryURL="https://wayf.aai.dfn.de/DFN-AAI-Test/wayf/www/WAYF.php">SAML2 SAML1</SSO>

I do not get the persistentId any longer. Furthermore, I can see the Session is using

SSO Protocol: urn:oasis:names:tc:SAML:1.1:protocol
Authentication Context Class: urn:oasis:names:tc:SAML:1.0:am:password

To me it seems as if the WAYF forces it to use SAML1, and that's why I do not obtain the entityID. Is that so?

Is there a discovery service I could use instead which will be SAML2 compatible and give me the persistentID?


thanks & best regards

Stefan

-- 
Kontaktdaten: https://portal.uni-ulm.de/ETB/ab/showPerson.html?pid=46110

-- 
Kontaktdaten: https://portal.uni-ulm.de/ETB/ab/showPerson.html?pid=46110

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Enforcing SAML2/transmission of persistentId for WAYF service?

Peter Schober
In reply to this post by Stefan Kombrink
* Stefan Kombrink <[hidden email]> [2019-11-21 08:24]:
> To me it seems as if the WAYF forces it to use SAML1, and that's why I do
> not obtain the entityID. Is that so?

Indeed. The flow for (obsolete) "WAYF" is different and goes from the
IDP Discovery Service direcly to the IDP. Avoid that anywhere/everywhere.

In the "SAMLDS" flow the discovery service sends you back to the SP
(with the selected IDP, of course) and only SP then sends you on to
the IDP by sending an authn request (as usual) with whatever
properties the SP requires. That allows the SP to sign the authn
request, if so desired, or add policy to it depending on the IDP's
entityID.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]