Just to tie this up... Apache was configured to simply mod_proxy request to Tomcat.
Switched to proxy_ajp_module and https setting for apache: <IfModule env_module> # Fake SSL if Loadbalancer does SSL-Offload SetEnvIf Front-End-Https "^on$" HTTPS=on </IfModule> All working as expected now. Thanks, Bill On Tue, Aug 9, 2011 at 9:33 PM, William G. Thompson, Jr. <[email protected]> wrote: > 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
