Rock Solid Knowledge SAML Implementation
Our SAML component supports both SP-initiated and IdP-initiated SLO, with HTTP Redirect and POST bindings. We do not currently support any SOAP bindings. The SAML specification recommends using front-channel bindings for the initial request as it provides the best chance of successfully propagating the logout request to all involved SPs.
A significant problem with using front-channel redirection to propagate logout requests is that complete control is forwarded to all the target service providers iteratively. This means that the entire SLO process will fall over even if a single SP in the chain is unresponsive. The remaining SPs will never know that a failed logout attempt was made, resulting in various orphaned sessions, and the user will be displayed a generic HTTP error with no meaningful details from either the IdP or the SP.
We think this redirect chain approach is a bit old fashioned and not very user friendly. As a result, our implementation solves this problem by using iframes instead of HTTP redirection. Using iframes to make logout requests means that the IdP can send logout requests to all SPs in parallel, preventing the entire SLO chain from falling over due to one unresponsive SP.
You can find out how to enable SP-Initiated SLO and IdP-Initiated SLO in our SAML documentation.
Caveats
In a perfect scenario, SLO can improve the user experience and security by removing the need for end-users to manually log out of all SSO sessions. However, SLO has some significant restrictions and drawbacks, which make it fragile and challenging to implement.
Firstly, for SLO to work, both the IdP and all SPs must be configured to support SLO; otherwise, various sessions may not be terminated. If only partial logout was possible, the user might assume that the entire SLO process was successful and leave unattended sessions to be exploited.
SLO is one of the more opaque parts of the SAML protocol, with only a status code to work from for error messages. If you do not own all service providers, then this may be an issue when supporting users.
Lastly, front-channel SLO requires setting session cookies in browsers, which cannot be triggered from an admin portal. Furthermore, front-channel logout may no longer be a feasible solution in the future due to the upcoming browser changes to phase out third-party cookies. As such, back-channel logout is most likely to be the only solution moving forward; however, it requires a lot of orchestration and additional development effort to implement SOAP and SP-level session blacklists, where the SP must maintain a record of all logged out session IDs.
Conclusion
SAML SLO can improve the user experience and security by removing the need for the end-user to manually log out of all sessions established during SSO. However, SLO is by no means a perfect solution, as it has specification restrictions and technical difficulties, which make it fragile and challenging to implement. Therefore, SLO only mitigates issues of orphaned SSO sessions but does allow the user to log out with (more) confidence.
Check out our SAML component page for more information.