SOAP SLO handler: what would it be used for?

[Cantor, Scott]

On 4/16/14, 1:48 PM, "Tom Scavo" <trscavo at gmail.com> wrote:

>On Wed, Apr 16, 2014 at 1:07 PM, Wessel, Keith <kwessel at illinois.edu>
>wrote:
>>
>> Looks like /idp/profile/SAML2/SOAP/SLO also uses back channel
>> communicationsŠ and we can turn that off, too. I¹m just curious, though,
>> what would be a use case for a SOAP SLO call? Non-interactively
>>terminating
>> a user¹s session?

Depends what you mean by non-interactive, I guess, that's just how back
channel logout is done.

>An inbound SOAP-based SLO endpoint doesn't seem to be very useful.

That's because logout isn't. If you solved all the inherent problems with
applications, that would be a much more desirable logout binding, and much
more efficient. Front channel logout on the other hand is inherently
ridiculous.

>However, outbound SOAP-based SLO is what's being implemented in v3, if
>I recall. If that's right, this means SPs will expose a SOAP endpoint
>for this purpose.

Yes, but if the IdP is doing that, it might as well support SOAP requests
too.

>>I assume that the SOAP SLO call uses a similar security model to artifact
>> resolution and attribute queries and thus should be turned off if we¹re
>> turning off the others. Is that correct?

Yes.

>>And finally, does ECP not use this security model? Looks like we have
>>that
>> running on 443, so I assume it¹s not using a cert from metadata. Is that
>> right?

An ECP client could implement itself to authenticate the IdP based on a
metadata-sourced key, and that would push it toward that port. Using 443
means you're stuck with the problem browsers have, trusting the server and
having no tools for doing so that aren't a joke.

Most clients today are certainly using 443 and doing nothing significant
to authenticate the IdP.

-- Scott