Page MenuHomePhabricator

CAS Single Logout Flow
Open, MediumPublic


The CAS protocol supports Single Logout with a separate /logout endpoint. This requires some support on the application to effectively end the session.

We could probably set up daily regression tests which log in and log out into registered services (to e.g. prevent that e.g. the logout functionality breaks when we upgrade to let's day a new version of an application).

Related Objects


Event Timeline

herron triaged this task as Medium priority.Sep 26 2019, 5:17 PM

Change 688249 had a related patch set uploaded (by Jbond; author: John Bond):

[operations/puppet@production] P:idp::client::httpd: add support for CASSSOEnabled

Change 688249 merged by Jbond:

[operations/puppet@production] P:idp::client::httpd: add support for CASSSOEnabled

MoritzMuehlenhoff renamed this task from Validate Single Logout Flow to CAS Single Logout Flow.May 20 2021, 10:33 AM

Status update:

The Single Logout has been implemented across all applications using mod_cas and tested for all affected applications. It works fine for all applications except LibreNMS (will create subtask). In addition there's a number of applications which are correctly logged out, but where the user experience leaves room for improvement (e.g. the client-side logic of the application is still in the browser, but no further data can be retrieved with irritating error messages). I'll also create sub tasks for these, there might be options to trigger an explicit logout within the applications.

Currently the session logout was initiated by the user clicking "Log out" at Since SREs also need have a way to force the log out of other users, I tested available options present in the ssoSessions actuator. This actuator is restricted to localhost on the IDP hosts. In theory "curl" should return us a JSON of all current sessions. Turns out however, that this functionality doesn't work with the Memcached session backend that we're using:

We can however for scripting purposes access the local memcached backend ourselves. This implementation is still TBD, but "sudo memcdump localhost:11000" also provides us with the list of TGTs currently active. Then we can send a DELETE request to /api/ssoSessions/$TGT and terminate a session for a different user, e.g.

jmm@idp-test1001:~$ curl -X DELETE