Currently, I’m spending time on installing the Yale CAS, which may be the core module of my company in the near future.
Central Authentication Service, abbreviated as CAS, is a system particular to provide authentication to other softwares. To make it clear, it just provides authentication, not including authourization, thus it just checks whether the username is matched to the password in the configured datasource.
After some investigations, I chose CAS from Yale University (Go) for a test. There are simple reasons for the choice. CAS is a freeware, and most importantly many clients are using and supporting it. Most of the clients are universities around the World.
The requirements for the configuration is not tough at all. It should be separated to server and client sides. For the server, what I’m using is listed:
Server Configuration (cas-server-3.0.5)
- Fedora Core Linux 4 / Windows XP Home Edition
- J2SE SDK 1.5.0_05 (J2SE 5 or above)
- Tomcat 5.0.28 / 5.5.12 (5.0.28+)
Client Configuration (cas-client-java-2.1.1)
Case 1:
- Windows XP Home Edition
- Tomcat 5.0.28
- J2SE SDK 1.5.0_05
Case 2:
- Windows XP Home Edition
- JBoss AS 4.0.2
- J2SE SDK 1.5.0_05
Case 3:
- Fedora Core Linux 4
- JBoss AS 4.0.2
- J2SE SDK 1.5.0_05
Case 4:
- Fedora Core Linux 4
- Tomcat 5.5.12
- J2SE SDK 1.5.0_05
Case 5:
- Fedora Core Linux 4
- Tomcat 5.0.28
- J2SE SDK 1.5.0_05
In the above cases, only Case 1 and 5 are successful to me. In fact, since all my stuff run on JVM, so operating system should not be a problem. Besides, the only common thing for the two cases is the Tomcat Container Version I used.
I was testing on three kinds of servers, Tomcat 5.0.28, Tomcat 5.5.12 and JBoss AS 4.0.2. On the latest two, I can successfully login and the browser direct me back to my original requested page. At this moment, problem occurs. See the stack trace as below:
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1233)
at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:129)
at edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:391)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:534)
After viewing the code of CASFilter on line 391, I guessed the problem comes from the CASReceipt class, where it is not serializable. May be the two servers have some logics which enforce the use of Serializable on all objects through the server, thus make it fails. After that, thanks for the proof from Scott Battaglia, and the case is logged to Yale CAS Client JIRA Instance (http://tp.its.yale.edu/jira/browse/JCC-21)
Besides that, I did also have a tricky problem and its solution, which is setting the SSL issues. Normally, we can follow the instructions of this (http://www.ja-sig.org/products/cas/server/ssl/index.html). However, for most newbie like me, we must not know when setting the self-defined certificate, we should set the common name (CN) to be the same as the server address (for example, both are localhost).
Last, but not least, I found an interesting issue. When you’re doing a form submission using POST method, and the requested action is the one need to be authenticated (need a redirect to CAS page), the requested action is at last called by GET method, instead of POST. It brings me a question, will my original parameter value exposed in this change of method. I’m still finding the answer, but it seems the application can still hide those POST parameters.








