jasig-cas IRC Logs-2011-09-24

[07:12:49 CDT(-0500)] <ries> Good morning, I am getting in CAS 3.4.10 "You are currently accessing CAS over a non-secure connection……." However, I configured apache to use SSL and glassfish is just behind that.
[07:13:16 CDT(-0500)] <ries> I tried to add SetEnvIf Front-End-Https "^on$" HTTPS=on in Apache (I was reading that somewhere) but I still get the warning
[07:36:14 CDT(-0500)] <apetro> yup. There's almost certainly some configuration you also need to do in GlassFish to get it to accept the environment characteristics being set by Apache.
[07:47:58 CDT(-0500)] <ries> apetro: so, SSO will still not work as advertised in such situation?
[07:48:13 CDT(-0500)] <ries> I was somewhere else reading that some guy had the issue, but everything worked...
[07:48:29 CDT(-0500)] <ries> Currently my SSO works pretty good, but Single Sign Off doesn't
[07:49:19 CDT(-0500)] <ries> so I am looking into directions of possible causes...
[07:49:23 CDT(-0500)] <apetro> ah
[07:49:43 CDT(-0500)] <apetro> so, single sign on won't work without SSL, by default
[07:49:59 CDT(-0500)] <apetro> because single sign on is mediated by a secure cookie between browser and CAS.
[07:50:07 CDT(-0500)] <ries> Correct, I noticed that and have configured SSL on my apache frontend...
[07:50:23 CDT(-0500)] <apetro> If the browser believes that it is not accessing CAS via SSL, then it will not present the secure cookie
[07:50:27 CDT(-0500)] <ries> Now, when I have two applications, SSO works… I login into one app, then when I reload my other app I get logged in
[07:50:33 CDT(-0500)] <apetro> CAS will fail to recognize the user, so the user will again be prompted to login.
[07:50:36 CDT(-0500)] <apetro> however
[07:50:44 CDT(-0500)] <apetro> all of that was just about what the browser believes
[07:51:09 CDT(-0500)] <apetro> that is, whether the browser is really using SSL to access CAS, and apparently you've solved that with your Apache config
[07:51:14 CDT(-0500)] <apetro> browser is really and actually using SSL
[07:51:25 CDT(-0500)] <apetro> glassfish just hasn't gotten the memo about that, so hasn't told CAS, so CAS will nag you.
[07:51:27 CDT(-0500)] <ries> yes, 100% sure.. I can see the certificates
[07:51:35 CDT(-0500)] <apetro> yup
[07:52:05 CDT(-0500)] <apetro> CAS, from its perspective, thinks the browser isn't accessing it via SSL, because that's what Glassfish is telling it when CAS asks ServletRequest.isRequestSecure()
[07:52:24 CDT(-0500)] <ries> correct....
[07:52:25 CDT(-0500)] <apetro> you could get CAS to be nominally happier by figuring out how to get GlassFish to tell it that it's secure
[07:52:29 CDT(-0500)] <apetro> but it doesn't matter
[07:52:41 CDT(-0500)] <apetro> you can just as well delete the nag snippet from the login JSP
[07:52:52 CDT(-0500)] <ries> I was planning to, to be honest
[07:52:54 CDT(-0500)] <apetro> CAS doesn't function any differently depending upon its belief about SSL
[07:53:05 CDT(-0500)] <apetro> it's just trying to remind you that SSL is important with the nag message
[07:53:40 CDT(-0500)] <apetro> because, of course, much of the time the reason the container is telling CAS it's not secure is that it's really not secure, and that would be, well, not secure.
[07:54:18 CDT(-0500)] <apetro> I don't see what any of this has to do with single log out, so if that bit was important to you, maybe we need to talk about and think through that some more.
[07:54:55 CDT(-0500)] <apetro> otherwise, now that I've shared my SSO-requires-browser-belief-of-SSL rant, what's this about SSO works for one app but not the other?
[07:55:40 CDT(-0500)] <ries> Could it be that Single Logout only works for applications behind SSL?
[07:55:55 CDT(-0500)] <ries> I just configured one app to function behind SSL, and now single sign out worked...
[07:56:30 CDT(-0500)] <apetro> I don't see why SSL would have anything to do with it
[07:56:48 CDT(-0500)] <ries> trying to get my head around it...
[07:57:02 CDT(-0500)] <apetro> except that the service being behind SSL adds an additional opportunity for failure (CAS server might not trust the SSL cert of the service being singly logged out of and so the CAS-generated HTTPS request could fail to connect.)
[07:57:34 CDT(-0500)] <apetro> well
[07:57:48 CDT(-0500)] <apetro> did putting it behind SSL cause the CAS server to have a viable network path to make the logout request?
[07:58:39 CDT(-0500)] <apetro> Single Log Out is a feature where the CAS server is itself makng http:// or https:// requests to the services using CAS, as identified by their service=SPLAT URL from /cas/login?
[07:59:11 CDT(-0500)] <ries> I am just accessing logout by issuing : https://<server>/cas/logout
[07:59:21 CDT(-0500)] <apetro> ah
[07:59:44 CDT(-0500)] <apetro> so regular old termination of the CAS session is accomplished by doing that.
[08:00:16 CDT(-0500)] <apetro> If the end user's browser accesses that URL, then CAS will invalidate the TGT as identified by the browser's TGT cookie. Invalidate server-side. single sign-on session terminates.
[08:00:47 CDT(-0500)] <apetro> optionally, additionally, CAS can heroically itself call back to the services the user logged into in the course of that session and advice them that the session has expired so that they can heroically delete the user's session or whatever they're going to do about it.
[08:01:44 CDT(-0500)] <ries> is that the standard behavior of CAS?? optionally, additionally, CAS can heroically itself.....
[08:01:53 CDT(-0500)] <ries> I was about to see in my headers what happens..
[08:02:14 CDT(-0500)] <apetro> it's the default-on behavior in the latest releases of CAS, but it's nowhere in the CAS protocol.
[08:06:36 CDT(-0500)] <ries> weird weird… in firefox it works...
[08:06:41 CDT(-0500)] <ries> Logout that is
[08:08:17 CDT(-0500)] <apetro> where doesn't it work?
[08:08:30 CDT(-0500)] <ries> In Safari
[08:08:52 CDT(-0500)] <apetro> and, sorry, what again exactly doesn't work?
[08:09:01 CDT(-0500)] <ries> Logout of all applications
[08:09:34 CDT(-0500)] <ries> ok.. it must had been some hanging cookie...
[08:09:58 CDT(-0500)] <ries> I removed all cookies, restarted safari and now I get the correct behavior
[08:10:04 CDT(-0500)] <apetro> session cookie with a CAS-using application that you'd previously logged in to, you mean?
[08:10:11 CDT(-0500)] <ries> yes..
[08:10:54 CDT(-0500)] <ries> Is the order of the filter mapping importand for CAS? i put the logout filter at the top of all filter-mappings
[08:11:10 CDT(-0500)] <ries> this wasn't the case for on the of the applications where logout didn't work
[08:11:37 CDT(-0500)] <ries> I 'think' I have read that some where (a couple of days ago) but in the documentation on jasig I didn't find that anymore
[08:12:10 CDT(-0500)] <apetro> Some of the order of the client library filters matters, yes.
[08:12:58 CDT(-0500)] <ries> you have been very helpful again, thanks!
[08:13:04 CDT(-0500)] <apetro> I don't know offhand what the constraints are on the logout filter particularly, but I would imagine that filter needs to be first to intercept the single log out POST that is posted to the same URL where the ST is presented on a GET request for login.
[08:13:08 CDT(-0500)] <ries> Seems like everything works now as expected..
[08:13:16 CDT(-0500)] <apetro> Glad it worked out.
[08:13:35 CDT(-0500)] <ries> for one application I had it on top, that worked, when it's at the bottom, it didn't work..
[08:14:05 CDT(-0500)] <ries> I remember I copied them from the site yesterday, but only faughly remembering it needed to be on top from a other website...
[08:14:28 CDT(-0500)] <ries> yea a. I am very glad myself, because if this works.. then we can throw away the crap they tried to invent themselve
[08:15:10 CDT(-0500)] <ries> With the SSO system they designed internally there are issues when users behind proxy servers are accessing the systems...
[08:15:42 CDT(-0500)] <ries> very hard to duplicate… and with 13K users.....
[08:17:28 CDT(-0500)] <ries> I will keep hanging around though
[08:17:52 CDT(-0500)] <apetro> please do