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
<https://source.jasig.org/cas3/tags/cas-server-3.4.9/cas-server-core/src/main/java/org/jasig/cas/web/flow/SendTicketGrantingTicketAction.java>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
<https://source.jasig.org/cas3/tags/cas-server-3.4.9/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml>.
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
