Timothy: Yes with a mix of trusted certs in /jre/lib/security and $JBOSS_HOME/server/default/conf . My situation is very complicated and I'm still having issue with reverse proxy with Apache. I'll try to explain my setup in more detail.
This is going to be lengthy. Once upon a time a government agency wanted common authentication for it's enterprise Java applications, web and web service type Java EE applications. This authentication had been poorly implemented using JAAS and user/password property files. I convinced them that CAS would be a good solution because it's commonly implemented and a module to connect to Microsoft Active Directory already existed. The agency agreed to allow the contract to implement this as long as adherence to state architecture was followed. Long story short this implementation has evolved as implementation progressed. Since reverse proxy using IIS was previously used with the insufficient Java/JBoss solution, the contractor has implemented Apache with AJP to Tomcat with CAS on a standalone server. Presentation, Business, and Database servers also exist behind firewalls to support the actual application hosting. Initially, reverse proxy was setup, configured, and used when HTTP was being used for integration and testing. Later when HTTPS was employed (with some difficulties) the Apache reverse proxy configuration failed. In order to maintain progress and support actual production use of the Java project deployments, we first allowed HTTP once the user was past CAS because even the presentation servers were on the internal agency network. Using HTTP on the presentation and business servers allowed our reverse proxy configuration to work. When we learned that HTTPS would have to be employed throughout the system, we approached this with testing and re-configuration again. The HTTPS solution has been successful, however reverse proxy has not. That's still not to say that we can't make it work. We just haven't yet. I would term the HTTPS implementation as a certificate frenzy. CAS is difficult to understand and once you fully understand those steps you need to multiply the same steps by two to account for each of the certificate exchanges. I'll ignore the LDAP certificate, but try to explain the CAS-to-application mechanisms again. The user sends a request to the CAS server and it sends a certificate from the apache server. The user browser trusts this saying ok to the CAS server. The CAS server proceeds to process the request for the CAS login to access the ultimate application service. The request is passed from Apache, as the AJP protocol, through port 8009 internally and then to the CAS server running in Tomcat on port 8443 internally. This Tomcat does not require a certificate or public-private keystore that would be registered with the servlet container's connector. This solution utilizes the Apache-AJP technology to employ the same certificate that's sent even when a static HTML page is requested via HTTPS. The CAS server application redirects the request to the application server using an HTTPS URL. The application server is not setup with Apache and it's Tomcat servlet container does have to associate a certificate and public-private keystore with it's internal port 8443 connector. This certificate has to be imported into cacerts on the Apache machine at $JAVA_HOME/jre/lib/security . When the application server is called upon by the redirect, it's server sends a certificate from $JBOSS_HOME/server/default/conf/mykeystore.jks that contains a public certificate. This certificate is sent to the Apache/CAS server. The java environment has to trust the certificate or this complicated chain of events will fail. Remember too that the user (via his browser) cannot override or accept any untrusted certificate. Now this is out of the way let's return to the request. The request was from the user initially and he had asked to be authenticated to use a particular application service. The application server now parses the URL parameters obtaining a uniquely generated service ticket that CAS sent. My analogy is "hey, I have an unknown user out here that wants to use our phone." The guy yelling that, or the CAS server also wrote a made up number on a slip of paper and gave it to the guy behind the door in the back. The application makes up a new HTTPS URL and attaches the slip of paper with the number or really the CAS service ticket. It's important to note that Java code in the application server's CAS client filter is going to make a brand-new socket connection utilizing SSL/TLS that's secure because it knows who this host will be and it will have to trust the certificate that will be ultimately sent from that host. Once again, the Apache server is called programmatically and it sends its certificate this time to Java on the application server. This Java is actually the Java Virtual Machine that's running the service application. And, this request is in the program execution chain of the application request. You must import the Apache certificate in $JAVA_HOME/jre/lib/security/cacerts on the application server. If you're running multiple JVMs like we are, you must import this certificate into it's cacerts. We're still not done. The CAS client sent this HTTPS request with the service ticket back to the CAS server and asked, "ok, if this guy want's to use our phone, you get his credentials and let me know you're cool with it. If so, I'll pass out the phone, we're busy in here doing secret things." The CAS server presents the user and password screen, the authentication occurs, and when this (request for authentication) returns to the CAS client acceptable, the service request (also HTTPS) can now be served from the application server. Since, the application server is not fronted with Apache, the JBoss internal Tomcat is hosting an 8443 connector and it will be sending it's public certificate back to the user's browser or in the reverse proxy case, back to Apache to be proxied. I know that I've probably overwhelmed you but this really is overwhelming when it's analyzed at a granular level. Hopefully, you can get your implementation working. I stand firmly behind the mechanics of how CAS works. Yes it's complicated but it also is what's securing your applications from unwanted visitors. Thanks, David On Fri, Jan 23, 2009 at 10:21 AM, Timothy Tagge <[email protected]> wrote: > David, > Were you able to solve the issue as you described it? > > On Thu, Jan 22, 2009 at 5:22 PM, David Whitehurst > <[email protected]> wrote: > > Timothy: > > > > I've had nothing but troubles of a similar sort. Consider this; > > > > 1. HTTPS to initial URL with service sends cert from Apache server or > Tomcat > > CAS server to user browser. > > 2. The CAS client code creates a brand new HTTPS request back to the CAS > > server or Apache (if used) the same cert is coming in the direction of > the > > CAS client. So, Java has to 'trust' that certificate. And, if the > connector > > at the service application server is HTTP, the initial request won't just > > remain HTTPS. > > 3. After CAS authenticates the user, and acknowledges the CAS client that > > things are okay, the service application content (HTTPS) will come if > that > > server is hosting an HTTPS connector. If it is, Tomcat will send his > > certificate to the user browser. > > > > > > HTH > > > > David > > > > On Thu, Jan 22, 2009 at 6:02 PM, Timothy Tagge <[email protected]> > wrote: > >> > >> > >> > https://securetools.homefinder.com/SSO/login?service=https%3A%2F%2Fsecuretools.homefinder.com%2FAAT%2FeditAgent.do > >> > >> This service URL points to a controller, which then does a redirect to > >> a jsp page after processing, doing lookups etc. > >> > >> I'm starting to think that since it the browser shows the correct jsp > >> page, just minus the https, that CAS is not the issue. Perhaps it > >> could be Apache or Tomcat assuming http somehow. > >> > >> On Thu, Jan 22, 2009 at 4:07 PM, Scott Battaglia > >> <[email protected]> wrote: > >> > What is the actual service url on the CAS server? i.e. > >> > http://my.server.com/login?service=FOO > >> > > >> > -Scott > >> > > >> > -Scott Battaglia > >> > PGP Public Key Id: 0x383733AA > >> > LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> > > >> > > >> > On Thu, Jan 22, 2009 at 4:40 PM, Timothy Tagge <[email protected]> > >> > wrote: > >> >> > >> >> I added some log statements to the constructServiceUrl method of > >> >> CommonUtils which show the correct service. This filter is on the > >> >> application that attempts to load on http instead of the requested > >> >> https. > >> >> > >> >> public static final String constructServiceUrl(final > HttpServletRequest > >> >> request, > >> >> final > >> >> HttpServletResponse response, final String service, final String > >> >> serverName, final String artifactParameterName, final boolean encode) > >> >> { > >> >> System.out.println("service:" + service); > >> >> System.out.println("serverName:" + serverName); > >> >> System.out.println("artifactParameterName:" + > >> >> artifactParameterName); > >> >> System.out.println("encode:" + encode); > >> >> > >> >> > >> >> The results of these statements..... > >> >> service:null > >> >> serverName:https://securetools.server.com > >> >> artifactParameterName:ticket > >> >> encode:true > >> >> > >> >> > >> >> One more thing I would add is that I'm using a host file on these > >> >> servers so that certificates can be shared over several servers (dev, > >> >> int, qa, etc) > >> >> > >> >> On Tue, Jan 20, 2009 at 9:21 PM, Scott Battaglia > >> >> <[email protected]> wrote: > >> >> > What's the service url being passed to CAS? > >> >> > i.e. /login?service=FOO > >> >> > > >> >> > -Scott > >> >> > > >> >> > -Scott Battaglia > >> >> > PGP Public Key Id: 0x383733AA > >> >> > LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> >> > > >> >> > > >> >> > On Mon, Jan 19, 2009 at 5:07 PM, Timothy Tagge < > [email protected]> > >> >> > wrote: > >> >> >> > >> >> >> CAS Server 3.3 > >> >> >> CAS Client 3.1.3 > >> >> >> Tomcat 5.1.15 > >> >> >> > >> >> >> Sending a redirect to > >> >> >> https://servername/AAT/doSomething.do > >> >> >> is ending up on > >> >> >> http://servername/AAT/doSomething.do > >> >> >> > >> >> >> > >> >> >> > >> >> >> Contents of web.xml CAS setup for AAT ... > >> >> >> > >> >> >> <!-- Filter Definitions > >> >> >> ***************************************************--> > >> >> >> <filter> > >> >> >> <filter-name>CAS Single Sign Out Filter</filter-name> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> > >> >> >> </filter> > >> >> >> <filter> > >> >> >> <filter-name>CAS Authentication > Filter</filter-name> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > > <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> > >> >> >> <init-param> > >> >> >> > <param-name>casServerLoginUrl</param-name> > >> >> >> > >> >> >> <param-value>https://servername/SSO/login</param-value> > >> >> >> </init-param> > >> >> >> <init-param> > >> >> >> <param-name>serverName</param-name> > >> >> >> > >> >> >> <param-value>https://servername</param-value> > >> >> >> </init-param> > >> >> >> </filter> > >> >> >> <filter> > >> >> >> <filter-name>CAS Validation Filter</filter-name> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > > <filter-class>org.jasig.cas.client.validation.Cas10TicketValidationFilter</filter-class> > >> >> >> <init-param> > >> >> >> > >> >> >> <param-name>casServerUrlPrefix</param-name> > >> >> >> > >> >> >> <param-value>https://servername/SSO</param-value> > >> >> >> </init-param> > >> >> >> <init-param> > >> >> >> <param-name>serverName</param-name> > >> >> >> <param-value>https://servername > >> >> >> </param-value> > >> >> >> </init-param> > >> >> >> <init-param> > >> >> >> <param-name>useSession</param-name> > >> >> >> <param-value>true</param-value> > >> >> >> </init-param> > >> >> >> </filter> > >> >> >> <filter> > >> >> >> <filter-name>CAS HttpServletRequest Wrapper > >> >> >> Filter</filter-name> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > > <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> > >> >> >> </filter> > >> >> >> > >> >> >> <!-- Filter mappings > >> >> >> *************************************************--> > >> >> >> <filter-mapping> > >> >> >> <filter-name>CAS Single Sign Out Filter</filter-name> > >> >> >> <url-pattern>*.do</url-pattern> > >> >> >> </filter-mapping> > >> >> >> <filter-mapping> > >> >> >> <filter-name>CAS Authentication > Filter</filter-name> > >> >> >> <url-pattern>*.do</url-pattern> > >> >> >> </filter-mapping> > >> >> >> > >> >> >> <filter-mapping> > >> >> >> <filter-name>CAS Validation Filter</filter-name> > >> >> >> <url-pattern>*.do</url-pattern> > >> >> >> </filter-mapping> > >> >> >> > >> >> >> <filter-mapping> > >> >> >> <filter-name>CAS HttpServletRequest Wrapper > >> >> >> Filter</filter-name> > >> >> >> <url-pattern>*.do</url-pattern> > >> >> >> </filter-mapping> > >> >> >> > >> >> >> <!-- Listeners > >> >> >> *************************************************************--> > >> >> >> <listener> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > > <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class> > >> >> >> </listener> > >> >> >> _______________________________________________ > >> >> >> Yale CAS mailing list > >> >> >> [email protected] > >> >> >> http://tp.its.yale.edu/mailman/listinfo/cas > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Yale CAS mailing list > >> >> > [email protected] > >> >> > http://tp.its.yale.edu/mailman/listinfo/cas > >> >> > > >> >> > > >> >> _______________________________________________ > >> >> Yale CAS mailing list > >> >> [email protected] > >> >> http://tp.its.yale.edu/mailman/listinfo/cas > >> > > >> > > >> > _______________________________________________ > >> > Yale CAS mailing list > >> > [email protected] > >> > http://tp.its.yale.edu/mailman/listinfo/cas > >> > > >> > > >> _______________________________________________ > >> Yale CAS mailing list > >> [email protected] > >> http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
