Is there a documentation opportunity here? (we had a discussion at work about changing all JIRA issues to opportunities :-))
On Wed, Aug 10, 2011 at 10:16 AM, William G. Thompson, Jr. <[email protected] > wrote: > 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 > > -- 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
