OneLogin and SLO?

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

OneLogin and SLO?

Jan Vilhuber
I was wondering if anyone successfully managed to set up SLO with OneLogin (I'm using one of their free test setups in the cloud, in case that matters). They do not support uploading of the SP Certificate (either separately nor via SP Metadata), meaning they don't really validate the LogoutRequest (we tested by sending an unsigned LogoutRequest, and it was processed successfully), nor do they sign the LogoutResponse (resulting in a "Security of LogoutResponse not established." error from shibboleth).

I previously asked them (via support case) about this, and they suggested I put the logout URL (as opposed to the SLO Endpoint URL) into the OneLogin configuration, which strikes me as an insecure work-around, and doesn't address the lack of signing of their LogoutResponse or validation of the LogoutRequest. They also suggested I turn off validation on my end to avoid the error (which... you know... really?!).

Is there some magic I'm missing? Can someone share a success story (and config examples)?

Alternatively, am I overreacting, and the lack of validation and signing of the Logout messages isn't a big deal?

Jan

--
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: OneLogin and SLO?

Cantor, Scott E.
> Alternatively, am I overreacting, and the lack of validation and signing of the
> Logout messages isn't a big deal?

We simply follow the standard, which isn't ambiguous on this question. If you want a rationale I can manage a poor one (*), but ultimately, my attitude is that once an implementation decides it knows better than the standard what should be done I can guess that they have decided they know better about things that are probably much more important and aren't so easy to let slide.

-- Scott
 
(*) Technically the reason is that the report of whether logout succeeded or not would have significant impact on the UI presented to the user and has to be trustworthy (making the response more crucial to sign than the request), but in practice logout never works reliably anyway and we don't really believe the SP should be presenting that UI, so that's a fairly poor rationale. Even worse, the Shibboleth IdP doesn't even have a way to know whether logout was complete or partial by the time it responds, so its responses aren't even strictly accurate.

--
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: OneLogin and SLO?

Jan Vilhuber
To close the loop on this: I filed a support request with OneLogin asking them for comment, pointing out that (in my opinion) there's a security hole in their product's handling of the SAML SLO messages (they neither check the signature of the LogoutRequest, nor do they sign the LogoutResponse), and they essentially (in so many words) said "We don't care. You can file an enhancement request, and if enough people vote on it, we might implement it."

I do agree that SLO is poorly understood by product owners and customers and shouldn't be used like an 'old style logout button'. But that appears to be an uphill (up-cliff?) battle.
jan

> -----Original Message-----
> From: users <[hidden email]> On Behalf Of Cantor, Scott
> Sent: Tuesday, July 10, 2018 7:51 PM
> To: Shib Users <[hidden email]>
> Subject: RE: OneLogin and SLO?
>
> > Alternatively, am I overreacting, and the lack of validation and
> > signing of the Logout messages isn't a big deal?
>
> We simply follow the standard, which isn't ambiguous on this question. If you
> want a rationale I can manage a poor one (*), but ultimately, my attitude is that
> once an implementation decides it knows better than the standard what should
> be done I can guess that they have decided they know better about things that
> are probably much more important and aren't so easy to let slide.
>
> -- Scott
>
> (*) Technically the reason is that the report of whether logout succeeded or not
> would have significant impact on the UI presented to the user and has to be
> trustworthy (making the response more crucial to sign than the request), but in
> practice logout never works reliably anyway and we don't really believe the SP
> should be presenting that UI, so that's a fairly poor rationale. Even worse, the
> Shibboleth IdP doesn't even have a way to know whether logout was complete
> or partial by the time it responds, so its responses aren't even strictly accurate.
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]
--
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: OneLogin and SLO?

Cantor, Scott E.
> To close the loop on this: I filed a support request with OneLogin asking them
> for comment, pointing out that (in my opinion) there's a security hole in their
> product's handling of the SAML SLO messages (they neither check the
> signature of the LogoutRequest, nor do they sign the LogoutResponse), and
> they essentially (in so many words) said "We don't care. You can file an
> enhancement request, and if enough people vote on it, we might implement
> it."

Pretty much expected, but thanks for trying, and posting back about it.
 
-- Scott

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