Decide what to do about single log out

From a usability standpoint: users generally expect to have their CAS session continued across their browser in other tabs after they finish whatever task they are doing in one and log out there, unless they specifically select for CAS to log out all sessions. I know we'd have to have a lot of retraining just to break habits and expectations with #1.

#2 by default without a real description as to what's being done behind the scenes nor choice for it removes a decision which shouldn't be presumed. It does seem a poor choice.

I think #3 is the best educated approach to deciding on a site-by-site basis and weigh the pros and cons. It could also speed deployment though by falling back to no SLO until #3 could be implemented cleanly.

And to be clear, we have no problem implementing SLO for the CAS Server component, where the Drupal site acts as the CAS login server.

The problem is that when Drupal is used as a CAS client, we cannot appropriately handle a "single log out" request that an external CAS server makes. This request comes in the form of an HTTP POST request containing the CAS service ticket for that user's session. We would normally store a mapping of this CAS service ticket to a local Drupal user's session ID, but we cannot do that in Drupal 8 because the session ID is not stored plaintext in database, instead it is stored as a hash.

I think #3 is the best bet as well. Honestly it seems like a horrible compromise, to remove a security feature to implement SLO, but if someone really needs it, then so be it. It won't be any worse off than Drupal 7 was I guess. We just have to provide a nice human readable description of this problem directly in the module.

1. +++ b/src/Controller/ServiceController.php
   @@ -90,11 +90,10 @@ class ServiceController implements ContainerInjectionInterface {
   +    if ($request->getContentType() === 'xml') {
   

   Why the change here?

2. +++ b/src/Form/CasSettings.php
   @@ -173,20 +173,28 @@ class CasSettings extends ConfigFormBase {
   +        'cause session IDs to be stored unencrypted in the database.'),
   

   should be "unhashed" not "unencrypted"

3. +++ b/src/Service/CasLogin.php
   @@ -148,17 +148,23 @@ class CasLogin {
   +        array('sid', 'plainsid','ticket'),
   

   missing a space after comma

4. +++ b/src/Service/CasLogout.php
   @@ -3,16 +3,41 @@
   +  /** ¶
   

   nit: extra space

5. +++ b/src/Service/CasLogout.php
   @@ -20,6 +45,16 @@ class CasLogout {
          // A quick look at SessionManager doesn't look good, as deleting a session
          // can only be done by a user. We cannot just delete the session record
          // from the DB because you can have session data stored elsewhere.
   

   This comment block should be updated?

I fixed two things:

(1) There were duplicate config schema's for the "logout" namespace, which was causing issues. Now all 3 logout config settings are together like they should be in cas.schema.yml

(2) When saving form config, I moved the new cas SLO setting to be alongside the other two logout settings

I also tested this with my local CAS server. The CAS logout service is indeed being invoked from the SLO POST request. However, it doesn't work. Our logic for clearing out a session doesn't work:

    session_id($sid);
    session_unset();
    session_destroy();
    session_write_close();
    session_regenerate_id(TRUE);

This fixes it so it works. We needed to call session_start(). I also removed session_unset() and session_write_close() since I don't think they were necessary?

I tested again and didn't find any notices in the log, so I committed it. Also changed the wording for the SLO setting a bit.

I'm still not completely happy with this - but at least we have something in here that works.