This email is admittedly pedantic, but these details may be important to understanding what's going on with lack-of-SSO here.
Specifically in the context of CAS single sign-on, that is, whether users will experience the login form each time they try to log in to a potentially SSO-participating service in the course of an established CAS single sign-on session: Original question: > I can login to any of the application, but when I login to one application and > try to open another application it always shows me login page. Led to answer: > The only requirement is that the hosts _think_ they are over a secure channel. To which I say: No. First, it's not "hosts". For purposes of SSO functionality, secureness of channel to access the CAS-using services is irrelevant. Services using CAS can present themselves entirely over http:// and still participate in CAS single sign-on. This is a worst practice to be sure, but functionally it will work fine. A service can think whatever it wants about whether it's being accessed securely and that will have no effect on whether CAS delivers a single sign-on experience, since that experience is entirely delivered by the CAS server and the service has fully handed off control at this point. Services can opt-out of participating in single sign-on only by setting renew=true on the redirect to CAS login or by a services registry registration indicating they do not participate in SSO. [1] Focusing on the CAS server, then: the requirement *isn't* that CAS thinks it's over a secure channel. This came up recently on the cas-dev list here <https://lists.wisc.edu/read/messages?id=15061798>. [2] Regardless of whether CAS thinks it's over a secure channel, CAS will send the ticket granting ticket cookie to the browser. Rather, it's all about what the *browser* thinks, not what the CAS server thinks. ServletRequest.isRequestSecure() is not the definitive test here. It's possible to configure an SSL endpoint in front of CAS (say, Apache httpd or a fancy hardware load balancer appliance) such that the browser thinks the interaction is over https:// / SSL (indeed, the interaction *really is* over https:// from the perspective of the browser), but the Servlet Container *doesn't* think the interaction is over https:// in part because the Servlet Container isn't, is too far behind, the SSL endpoint. In this case, isRequestSecure() will return false, but SSO will work just fine. So long as the browser thinks it's accessing CAS over https://, the browser will send that TGC ticket granting cookie back to CAS on a subsequent login request. So long as the browser sends that cookie, CAS will read that cookie, regardless of whether CAS thinks it has been accessed securely. And so long as that cookie points to a valid TGT, that is, a valid CAS SSO session, and the target service hasn't opted out of single sign on, CAS will provide a single sign on experience. No additional prompting with login screen. However... > I have network configuration, where I have firewall and balancer which > receives https:// but in internal network redirect via http. Do you think it > can be a problem or not? The word "redirect" scares me there. Redirect, as in the browser does a redirect? If the browser is redirected to an http:// URL, then it's no longer operating over https://, and the browser won't send the TGC cookie on that subsequent request. (Also, the login isn't secure over http://, so in this case you'd have bigger problems than the inconvenience of no single sign on.) Here's what it comes down to: does the browser send the TGC cookie (because the browser believes the request is over https:// and matches the scope of the cookie) and can the CAS server see the TGC cookie when the browser sends it? Is the TGC cookie being lost in the flow of traffic from that fronting balancer to the actual CAS server? [1]: Using https:// / SSL is an important practice and all services using CAS should present themselves over https:// . If your service isn't receiving the CAS service ticket and presenting itself to authenticated users over https:// , you're risking session hijacking. Not using SSL is a worst practice -- please don't misinterpret my email as endorsing the practice. I'm only trying to make the technical point that CAS SSO will work just fine without services presenting themselves over https:// [2]: https://lists.wisc.edu/read/messages?id=15061798 , especially this email in the thread: https://lists.wisc.edu/read/archive?id=15069778 On 8/24/2011 11:19 AM, Marvin Addison wrote: >> Does it mean that if all my applications accessible over HTTPS even on >> different >> domains SSO will work? > The CAS clients can be on any number of domains; but there's no way to > scope the CAS SSO cookie to anything other than the domain where the > CAS server lives. > >> I have network configuration, where I have firewall and balancer which >> receives https:// but in internal network redirect via http. Do you think it >> can be a problem or not? > The only requirement is that the hosts _think_ they are over a secure > channel. The definitive test is that > http://download.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#isSecure%28%29 > returns true for a Java application. I don't operate in this kind of > environment, but I believe there are configuration knobs you can turn > to make the host to believe it's secure even if the server connection > handler isn't terminating SSL. > >> Is it possible in test mode switch off "secure" flag? > Yes, see the SSL section of > https://wiki.jasig.org/display/CASUM/Securing+Your+New+CAS+Server. > > M > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
