If you're terminating SSL at your load balancer you have two options: 1. Provide the explicit service url in the CAS client configuration. This of course limits your ability to send dynamic service urls. 2. If you're fronting your application with Apache, you can usually set the variable that tells Tomcat/your app that HTTPS is enabled so that when it asks request.isSecure() it returns true.
Cheers, Scott On Fri, Feb 19, 2010 at 7:28 AM, n99 <[email protected]> wrote: > > Hello > > After reading many posts about the benefits of running your protected > webapp > over SSL so as to protect the service ticket, I've investigated one of our > applications and can't see how I can do this in this, I imagine common, > scenario: > > We have a load balancer used to terminate SSL for an application sitting in > tomcat. > The application is protected by the java 3.1 cas client filter. > > As I understand it from http://www.jasig.org/cas/cas1-architecture, > http://www.jasig.org/cas/cas2-architecture and our use of CAS: > > An authenticated https request to the LB arrives at the filter as http. > The CAS filter redirects the user to the CAS server with this http url as a > service param like > > > https://secure.its.yale.edu/cas/login?service=http://www.yale.edu/tp/auth.jsp > > On successful authentication the cas server creates a service ticket and > "then associates this ticket with the user who successfully > authenticated and the service to which the user was trying to authenticate" > By service here I'm assuming service=http://www.yale.edu/tp/auth.jsp > > Then the user is redirected back to the service with a service ticket > > http://www.yale.edu/tp/authenticate.jsp?ticket=opaque-ticket-string > > The cas filter makes a request to > https://secure.its.yale.edu/cas/servlet/validate sending the service and > ticket for validation > > "When the CAS receives a ticket through the validation URL, it checks > its internal database to determine whether it saved, in the past, a > ticket corresponding to the one it just received. If it did, and if the > service associated with that ticket matches the service that was passed > in by the application that's requesting validation, it returns the > NetID associated with that ticket to the requesting application. > Otherwise, it refuses to validate the request." > > > This all works fine. > > However if I want the url > > http://www.yale.edu/tp/authenticate.jsp?ticket=opaque-ticket-string to be > httpS://www.yale.edu/tp/authenticate.jsp?ticket=opaque-ticket-string to > protect the ticket, > how would I do this? > > 1 somehow forcing the client to redirect to > > https://secure.its.yale.edu/cas/login?service=httpS://www.yale.edu/tp/auth.jsp > will not work > as the CAS server will store an https service and the CAS client will > receive an http service request through the LB which results in > > org.jasig.cas.client.validation.TicketValidationException: ticket > 'xxxxxxx' > does not match supplied service > > 2 If I could just force the CAS service to redirect to https for the > service url then this would work but I can't see this config available at > > Am I missing something here? :) > > cheers > > Nomit > > -- > View this message in context: > http://n4.nabble.com/protecting-the-cas-service-ticket-from-man-in-the-middle-attacks-tp1561525p1561525.html > Sent from the CAS Users mailing list archive at Nabble.com. > > -- > 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 > -- 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
