To share what you want to know
You are currently browsing the archive for the CAS category.
To casify Wordpress mu, andrejciho provides a great solution to this making use of phpCAS 0.5.0.
Here are the instructions listed in his page, mainly:
These are done very well by walking through the instructions below:
http://www.andrejciho.com/wordpress-mu/wpmu-cas-integration/
During the research of CAS (Central Authentication Service), one of the problems that troubles me is the integration to the Stand-alone applications written in VB.
CAS generally only support web applications, which can allow applications to redirect to the CAS login page and do the login. Someone said I can implement my own service for calling remotely, but I’m totally lost upon this. Even the number of classes is not large, but the configuration can be very complicated.
One bad thing is that the documentation for CAS is not completed, it is not enough for doing much customization. Due to time constraint, may be I am not able to implement CAS in my company finally.
After the trials of running a standalone CAS server, I tried to work with my team on authenticating the user using Microsoft Active Directory. In my company, Active Directory(AD) is the most integrated database on staff information. So the success of authentication on Active Directory almost means the success of implementing central authentication service without changing a lot in the current environment.
However, during the testing stage on connecting the CAS Server to the AD, we have faced a lot of problems. AD is one implementation of Lightweight Directory Access Protocol (LDAP). The default CAS Server package contains two kinds of authentication handler in connecting LDAP servers, which are Fast Bind and Search-and-bind.
Tutorial - http://www.ja-sig.org/products/cas/server/ldapauthhandler/index.html
For the Search-and-bind, since the tutorial uses a secure connection to connect LDAP, but no one in my company know how to turn on the secure channel of LDAP, so we gave it up at a very early stage.
Then, we can only focused on the Fast Bind one. Our experience shows us that the configuration listed in the tutorial is not useful for AD. We can only say the configuration may differentiate when you are using different LDAP servers. The one in the tutorial is for OpenLDAP. According to the post here, I tried changing from “uid” to “cn” accordingly and it succeeded finally. My setting is finally like this.
It is so unexpected that the problem is caused here. It is because I used a software named LDAP Browser before to check the settings of the filter. It showed that using “uid” is valid in connecting the AD.
Besides that, during the investigation in connecting AD, someone told me that I should ignore the PartialResultsException by adding this:
<property name=”ignorePartialResultException” value=”true” />
I don’t know what it is for so far, may need to investigate in a later stage.
http://tp.its.yale.edu/pipermail/cas/2006-September/003417.html
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)
Client Configuration (cas-client-java-2.1.1)
Case 1:
Case 2:
Case 3:
Case 4:
Case 5:
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.