On Tue, Aug 9, 2011 at 9:32 PM, William G. Thompson, Jr. <[email protected]> wrote: > Thanks, Andrew for that bit of clarity...much appreciated. > > >> Should SendTicketGrantingTicketAction only send TGTs, by default, over >> connections it feels are secure? Or is that unneeded complexity? > > This seems like a reasonable thing to do since SSL is required for CAS > to operate securely, At the very least it would make the message > "...SSO WILL NOT WORK" true. :)
Otherwise we'll need to amend the message to "...WILL NOT WORK...unless..." :) Bill > > Bill > > > > On Tue, Aug 9, 2011 at 7:49 PM, Andrew Petro <[email protected]> wrote: >> The displayed warning is a function of whether CAS thinks it has been >> accessed securely. >> >> <c:if test="${not pageContext.request.secure}"> >> <div class="errors"> >> <p>You are currently accessing CAS over a non-secure connection. >> Single Sign on WILL NOT WORK. In order to have single sign on work, >> you MUST log in over HTTPS.</p> >> </div> >> </c:if> >> >> Without the server configuration to make Tomcat believe that the request is >> secure, httpServletRequest.isSecure() returns false, triggering this >> warning. >> >> >> >> Contrastingly, the "secure"nesss of the TGT cookie is all about instruction >> to the browser and not at all about whether the server thinks the request is >> secure. >> >> cf. >> http://static.springsource.org/spring/docs/3.0.5.RELEASE/api/org/springframework/web/util/CookieGenerator.html#setCookieSecure%28boolean%29 >> >> CAS will happily supply the TGT cookie over a connection it feels is >> insecure. There's no configuration or gating in >> SendTicketGrantingTicketAction to prevent sending the TGT cookie over >> non-secure connections. >> >> It's just that reasonable browsers, when possessed of a cookie marked >> "secure", won't choose to present it to a CAS server that, in the view of >> the browser, isn't accessed over SSL. By default, this cookie is marked >> secure. >> >> >> So, Bill's observed behavior is: >> 1) CAS server didn't think it was being accessed securely, so it displayed >> the login page warning. >> 2) CAS server indiscriminately provided the TGT to the browser anyway >> 3) The browser then chose to present that TGT cookie to the CAS server, even >> though the cookie is marked "secure" since, in the view of the browser going >> through the LTM etc., the connection was over https:// >> >> Should SendTicketGrantingTicketAction only send TGTs, by default, over >> connections it feels are secure? Or is that unneeded complexity? >> >> Andrew >> >> >> >> On 8/9/2011 2:52 PM, William G. Thompson, Jr. wrote: >> >> On Mon, Aug 8, 2011 at 9:52 PM, Scott Battaglia >> <[email protected]> wrote: >> >> If you're offloading SSL to the load balancer, and using Apache, you need to >> pass the appropriate parameter to Tomcat. >> >> Cool, thanks. I wasn't involved in the F5/Apache/Tomcat setup...I'll >> follow up with the sysadmins. >> >> >> You should have had to do that regardless, or I believe the cookie would not >> have been set correctly. >> >> Yeah, this is confusing me...because I'm seeing the message that SSO >> will not work and at the same time SSO is working fine. I can get a >> TGT via /cas/login/ and then get a ST vended for /casapp/protected >> without a credential challenge. >> >> Perhaps it's something specific to the environment? >> >> RHEL5: F5 (terminating SSL) -> Apache -> Tomcat 5 >> Apache config for Tomcat/CAS: >> >> <IfModule mod_proxy.c> >> ProxyRequests On >> ProxyVia Block >> >> >> <Proxy *> >> AddDefaultCharset off >> Order allow,deny >> Allow from all >> </Proxy> >> >> ProxyPass /cas http://localhost:8080/cas >> ProxyPassReverse /cas http://localhost:8080/cas >> >> ProxyPass /admin http://localhost:8080/admin >> ProxyPassReverse /admin http://localhost:8080/admin >> >> >> ProxyPass /casapp http://localhost:8080/casapp >> ProxyPassReverse /casapp http://localhost:8080/casapp >> </IfModule> >> >> Best, >> Bill >> >> >> ... >> >> On Mon, Aug 8, 2011 at 9:45 PM, William G. Thompson, Jr. <[email protected]> >> wrote: >> >> Folks, >> >> I've been working on a 3.4.8 Maven Overlay build that I'm deploying to >> RHEL/Tomcat/Apache running in the clear on 80, but on a private >> network behind an F5 LTM doing SSL and load-balancing. I did the >> 3.4.9 upgrade today and now I'm getting the CAS-991 messaging that I'm >> "accessing CAS over a non-secure connection...SSO won't work, etc". >> >> However, I am accessing the site over https (via the LTM) and SSO is >> working just fine. Is the messaging wrong or should SSO really not be >> working? >> >> Bill >> >> >> >> -- >> 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-dev > -- 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-dev
