<SSO>SAML2</SSO> does not enable ECP support

Description

Reported by Terry Fleury, moved from old Jira.

In the documentation at https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPServiceSSO , in the section "Element Content", it states that the "SAML2" element enables "SAML 2.0 Browser SSO and ECP profiles". I tried using this element in my shibboleth2.xml configuration as follows.

<!-- --------------BEGIN SESSIONS-------------------------- -->
<Sessions checkAddress="false" handlerSSL="false" relayState="ss:mem"
cookieProps="; path=/; secure">
<SSO discoveryProtocol="SAMLDS"
discoveryURL="https://wayf.incommonfederation.org/DS/WAYF">
SAML2 SAML1
</SSO>
<Logout>SAML2 Local</Logout>
<NameIDMgmt>SAML2</NameIDMgmt>
</Sessions>
<!-- --------------END SESSIONS-------------------------- -->

Browser-based access works as expected. But ECP access gets immediately redirected to the InCommon WAYF rather than doing any sort of ECP handling.

If I instead configure shibboleth2.xml using the (significantly more verbose) 2.3-style configuration, ECP works correctly. Notice the 'ECP="true"' attribute for the SAML2 <SessionInitiator> below. This configuration works for both browser SSO and ECP.

<!-- --------------BEGIN SESSIONS-------------------------- -->
<Sessions checkAddress="false" handlerSSL="false" relayState="ss:mem"
cookieProps="; path=/; secure"
handlerURL="/Shibboleth.sso">
<SessionInitiator type="Chaining" Location="/Login" id="InCommon"
isDefault="true" relayState="cookie">
<SessionInitiator type="SAML2"
template="bindingTemplate.html" ECP="true" />
<SessionInitiator type="SHIB1" />
<SessionInitiator type="SAMLDS"
URL="https://wayf.incommonfederation.org/DS/WAYF" />
</SessionInitiator>

<md:AssertionConsumerService Location="/SAML2/POST" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
<md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<md:AssertionConsumerService Location="/SAML2/ECP" index="4"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
<md:AssertionConsumerService Location="/SAML/POST" index="5"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
<md:AssertionConsumerService Location="/SAML/Artifact" index="6"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>

<LogoutInitiator type="Chaining" Location="/Logout">
<LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
<LogoutInitiator type="Local"/>
</LogoutInitiator>

<md:SingleLogoutService Location="/SLO/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:SingleLogoutService Location="/SLO/Redirect"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:SingleLogoutService Location="/SLO/POST"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="/SLO/Artifact"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

<md:ManageNameIDService Location="/NIM/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:ManageNameIDService Location="/NIM/Redirect"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:ManageNameIDService Location="/NIM/POST"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:ManageNameIDService Location="/NIM/Artifact"
conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
</Sessions>
<!-- --------------END SESSIONS-------------------------- -->

So it appears that ECP works with SP 2.4.2, but requires the older style configuration. The newer <SSO>SAML2</SSO> configuration doesn't work with my ECP tests.

Environment

None

Activity

Scott Cantor May 27, 2011 at 8:54 PM

Not clear yet what my intent was, but using properties on the <SSO> element doesn't carry through to the child plugins created inside the chain because of the order of initialization and other factors.

Fixed

Details

Assignee

Reporter

Original estimate

Fix versions

Affects versions

Created May 27, 2011 at 8:53 PM
Updated July 7, 2011 at 1:56 AM
Resolved June 6, 2011 at 12:23 AM