IdP v4 SLO issues when wilcard certificates for websites

[Lipscomb, Gary]

Hi Scott,

Changing the order in the metadata 

From 

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/SOAP"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/Redirect"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/POST"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/Artifact"/>

To

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/Redirect"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/POST"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/Artifact"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://onlinedevel.csu.edu.au/Shibboleth.sso/SLO/SOAP"/>


Seems to support the idea that it is sequence driven.

Initial testing show that SLO logout worked successfully after that change.
As you mentioned removing the SOAP SLO binding would guarantee the fix. I can do this for our own managed metadata, but may be impossible for federated metadata.

Regards
Gary


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, 14 August 2020 21:57
To: Shib Users <users at shibboleth.net>
Subject: Re: IdP v4 SLO issues when wilcard certificates for websites

On 8/14/20, 7:17 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>  SOAP logout should only happen as a  last resort,

That particular part may be an assumption bordering on "wish" on my part. It's intended to work that way but I believe there are similar issues with picking bindings in other areas that really never worked as intended (like dating back to V2) and I tackled that more recently.

If the SP that's failing has front-channel bindings in place but it's still picking SOAP, that's running into the same issue I worked on fixing to prevent overuse of the Artifact binding. That fix isn't shipping until 4.1 and it's off by default.

It therefore probably operates in metadata order, which is not ideal. If the SP claims to support SOAP it probably will use it if it's earlier in the list. Getting it out of the metadata if it didn't support SOAP*  would be choice #1.

All the other options are some mix of "supported/unsupported/no idea where they actually get handled" that will take a while to scrounge up and come up with a test scenario I can use to explore it. I need to do it, because it's an issue, but it won't be immediate.

-- Scott

* I'm *not* saying the wildcard thing means it doesn't support SOAP logout, I'm just applying common sense that almost nothing "really" supports SOAP logout.

-- 
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