Single Logout (SLO) is a feature that allows a user to terminate multiple authentication sessions by performing a single logout action. Implementing SLO is often a challenge in an environment where different organizations operate the identity provider (IdP) and service providers (SP) and have different requirements for what happens on a logout. Browser-mediated SLO is inherently brittle, because it requires all messaging to go through the browser and for the SP and IdP to be aligned. Unless the policies of the organizations that run the IdP and SP are aligned, SLO doesn’t work.
Why SLO Is a Business Problem
It all comes down to business reasons and policies. While many security professionals want SLO for security reasons, it is problematic for support and technical reasons and can give a false sense of security. Different organizations have different ideas about when a user should stay logged in and logged out. With one IdP that has one business policy and multiple SPs with each having potentially different business policies, it can get complicated.
For example, the educational institution runs their IdP to allow for seamless authentication to campus services. In this scenario, the campus might want a user to be logged out of the SP, but still remain logged into the IdP with an active session. However, when the user returns to the SP, the reauthentication happens behind the scenes due to an active IdP session and the user is often confused because they were not asked to provide their credentials to reauthenticate. Additionally, the organization that runs the SP may not initiate SLO or may expect that the IdP will respond and log the user out.
Where all of this leaves most of us is frustrated with SLO and in situations where we have to explain how SLO works for our organization. We recommend thinking through different scenarios and how you ideally want SLO to work for your organization and publishing it with other IT policies. And to be prepared to explain it many times.
Federation Guidance for SLO
Single Logout (SLO) is complex to configure, and can be difficult to execute completely across potentially hundreds of federated resources. If the Service Provider is managed by one organization and the Identity Provider is managed by another, the support for SLO may not align.
At this time, InCommon’s only requirement is that the IdP must support Single Logout signaling by having a logout endpoint that supports the SAML profile so that SPs can initiate a SLO request if desired.
REFEDS similarly outlines the complexities of SLO when addressing the impact of blocking third party cookies within SLO. They note that the use of cookies and user interface guidelines for full orchestration of SLO lie outside of the SAML standard, leaving each IdP and SP to develop their own processes and guidelines around the topic.
Cirrus Recommendations
Cirrus has the ability to support different business processes in line with customer business policies. At a minimum, in line with most federation guidelines, a well-behaved IdP should articulate how it will respond to SLO with a url that will either perform the logout or show a page that informs the user how to logout. Instead of SLO, we recommend using forced reauthentication by shortening session times for the IdPs and SPs that you have control over. This can help prevent users from getting stuck on a confusing error message, and as long as the session timeouts are reasonable most users don’t seem to mind reauthenticating.
Cirrus Bridge
For conditional access bridges, SLO is enabled by default. The bridge will send users to a generic logout page on EntraID or Okta. For Okta, there is a global setting that governs SLO, and you can learn more about it on their page on how to customize a sign-out page. For non-conditional access bridges that want to enable SLO, additional configuration is needed and you can submit a support ticket to start the conversation on how to configure.
Cirrus Proxy
To set up SLO for the Cirrus Proxy additional configuration is needed. Please submit a support ticket to start the conversation on how to configure.