...
When presented with these issues many individuals offer a protocol where only the initiating SP and the IdP communicate. There The goal is to destroy the SP's session and the IdP's session so that users would have to re-authenticate if they visit that SP again. This approach leaves all other SP sessions active and communicating to the user exactly what they have, and have not, been logged out of is likely not possible. Therefore, this approach increases the risk that a user might abandon a computer with active sessions and allow an unintended, and possibly malicious, user access to those serviceservices.
To put it tersely, any application that would attempt this approach is looking out only for themselves at the cost of compromising the security for every other application participating in the SSO system.
...
A web application developer should do one of two things to support single logout when using Shibboleth. The easiest is to remove all application level session management and rely solely on the Shibboleth SP's session management. In addition to gaining SLO support the modified application will immediately gain new session related features as they are added to the Shibboleth product and eliminate any confusion that may occur if the application's session's configuration differ differs from those that of the Shibboleth SP configuration (e.g. different session timeouts).
...
In summary, the issues surrounding the use of SLO generally fall in to either user experience issues or technical issues. Many user experience issues can be addressed if an orginisation organisation is willing to invest effort in educating its users (which requires an ongoing effort in order to catch new individuals). The user experience and correlated technical issue that occurs when an HTTP error occurs during the the use of front-channel bindings can not be addressed if accessibility requirements are also to be met. As such, back-channel bindings are most likely to be successful but usage requires web application to take the aforementioned prerequisite steps, work that many developers have expressed an unwillingness to undertake. This will leave many organisations at an impasse, choosing between a solution with a high risk of being insecure or forcing developers to make changes to applications throughout the organisation.