We are leveraging single sign out quite a bit with the cas server. Our cas server admins are very conservative with the time for cas tickets. They leave the time out at 2 hours.

This becomes a problem with single sign out, as the ticket timeout on the cas server forces a single sign out. This can happen while the user is actively working on a site. Auto-completes quit working in forms because the ajax calls fail as the user is no longer logged in. Flex applications that talk to web services quit working etc. This all happens not because the user is idle on a site, but because they haven't visited the cas server in two hours.

I'd like to consider putting a "check authentication when a site cookie expires" mechanism in cas so that the ticket gets renewed maybe every 1.5 hours on my site (the timeout would need to be configurable). Other ideas about how to solve this problem are welcome.

Comments

bfroehle’s picture

bfroehle commented

Of course the easiest fix would be to reconfigure the CAS server to encompass a normal workday...

Clearly you'd want to redirect to the CAS login page at an appropriate time -- i.e. a normal page request and not an AJAX callback. Is there a way to distinguish between these two cases in Drupal? If not I worry your proposed solution might cause as many issues as the bug it is trying to solve.

metzlerd’s picture

metzlerd commented

Yes, of course changing the server is the obvious soluiton, but I haven't been successful at convincing the system admins to do this. The AJAX callbacks can be protected by path exclusions in the redirect settings of the cas module. There isn't a common drupal convention for this but you can exclude pages from cas processing. The defaults (services, etc) capture the modules I know about that do this, and our flex applications have predictable urls. I haven't started coding on this yet, but I will need to soon.

bfroehle’s picture

bfroehle commented

Dave:

I hope you've been able to convince your sys admins to set a more reasonable timeout.

If not, I think this feature request is beyond the scope of the CAS module --- the vast majority of users would only be confused by it --- and hence it should live in custom code (or a sandbox project on d.o).

Can this be accomplished with only using hook_init or hook_boot, for example? You could user cas_user_is_logged_in() to see if it is a CAS user logged in and compare REQUEST_TIME with $user->login to see how old the session is. Then you'd just have to inject some redirection code and you'd be all set.

-Brad

metzlerd’s picture

metzlerd commented

No I have not. My users are still just living with this frustration.

At minimum, I think some kind of API level support for cas module will be required, otherwise I'd have to duplicate too much functionality. Basically I'd need to force a "Gateway" check happen regardless of the drupal session status. It's the CAS cookie that needs to be refreshed after all.

It's possible that the recent work you did on the gateway functionality related to thing what I need, but with a setting that checks periodically regardless of drupal login status, but I'll need to do more research on this.

My sysadmin suggested that I generate proxy validation tickets and renew them periodically, which is the information he found on this evidently common problem on the normal Cas Server support lists, but I don't think it's right to have to allow java functionality

I don't expect you to do anything about this, but at minimum I'll need to refactor the code so that I can force a cas gateway style authentication check from a helper module, having it honor all of the appropriate cas configuration settings.

I'd appreciate it if you could leave this issue open as a placeholder for that work.

bfroehle’s picture

bfroehle commented

I'd appreciate it if you could leave this issue open as a placeholder for that work.

No problem, that's why I left this open to begin with.

But at minimum I'll need to refactor the code so that I can force a cas gateway style authentication check from a helper module, having it honor all of the appropriate cas configuration settings.

This would be a welcome change. The monolithic cas_login_check() function should probably be split up into more logical chunks anyway. A similar (identical?) refactoring is needed to support the gateway check on sites with caching as we cannot call cas_login_check at hook_boot because not enough of Drupal (and its modules) have been loaded yet. So instead we'll need to call a simpler function to call in hook_boot which only polls the CAS server and returns the username (or NULL). Then if we need to log in a user we finish booting Drupal before proceeding with the user login.

Do we want to do this in the 6.x-3.x and 7.x-1.x branches? Or should we open up another development branch for this refactoring?

rychannel’s picture

rychannel commented
Issue summary: View changes

Our CAS admins have the timeout set at 20 minutes due to a specific requirement by another department. I think the module should have an option to ignore the CAS timeout and let Drupal / browser manage the session

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Read thru the CAS protocol and some other documents and didn't find anything regarding "ignoring" single sign out tickets, so I think it is OK to do that on our end if the user wants to, but doing so just skirts around the underlying issue, where we don't have client support for renewing CAS sessions.

This would probably go under advanced settings. An alternative to using a Cookie would be to use a session variable that indicates when the last renewal was done, and check on every page load if it should do a renewal. I like reducing the use of normal cookies if possible and just keeping the data in a session cookie.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented
Title: CAS Login Renewal » Provide a way to disable single-signout
Version: 6.x-3.x-dev » 7.x-1.x-dev

This is an old issue for D6, but I think parts of this request are still relevant.

I'm going to change this to a feature request for D7, where it's still not possible to disable single sign out, which would be a workaround for this problem.

In D8, we already have SSO disable by default, and it can be turned on optionally.

I don't think we can do something elegant to fix this. Redirecting the user back to the CAS server to renew the authentication still would not solve the problem completely, because it requires the user on the Drupal site make additional requests periodically so the logic can run to renew their auth. But if they open a node form and work on it for a long time, they can still have a problem.

Ultimately I think the problem is that Drupal does not have auto-draft support yet.