CAS May Be Easier in a Production Environment

Introduction

For Single Sign On (SSO), I truly believe that JA-SIG's Central Authentication Service (CAS) has the best open source solution. Notice how I adorned that statement with the terms "open source". If it's secure and it's freely available to the public, not hacked, used heavily by the public, and the implementations are fairly well documented, I'm sold. This does not mean that I haven't had my share of problems as with any other Java EE implementation. My solution will provide a CAS server on a portal server and the applications will reside on another server. For trial testing and demonstration purposes, I'm doing a first installation on a single Redhat server with JBoss. And, against CAS recommendations, I've been using localhost.

My first goal was to get CAS running as a SSO entry point with default authentication (same user, same password) and then redirect to one of three simple Web applications on JBoss. My first hurdle was having CAS trust the self-signed certificate needed for HTTPS. I first created a local keystore and tried to import this into $JAVA_HOME/jre/lib/security/cacerts. This didn't work. I'm not sure why but telling CAS specifically what keystore or cert to trust did. Consider the following section from security.xml in cas-server-webapp.

<bean id="casProxyTicketValidator"
       class="org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator"
               p:casValidate="${cas.securityContext.casProxyTicketValidator.casValidate}"
               p:serviceProperties-ref="serviceProperties">
               <property name="proxyCallbackUrl"><null /></property>
       <property name="trustStore">
             <value>/usr/local/cas/mykeystore.jks</value>
       </property>
</bean>

I had CAS working and was able to call an application and it immediately went to the CAS login to authenticate. Now, I would replace the simple authentication with the LDAP module and use an existing Active Directory on the Microsoft network. The users are all authenticated using these credentials when they boot their PC. If they want to access any of the JBoss applications, they will now authenticate just once at the login portal (CAS server).

Getting LDAP to work with the CAS LDAP module was a little tricky but again before I could query the LDAP server, I had to solve another trust issue with CAS and the LDAP certificate. The Microsoft administrator gave me the cert file from the LDAP server and I imported this into the keystore that I had generated earlier. This command was like this.

$keytool -import -trustcacerts -
keystore /usr/local/cas/mykeystore -storepass 123456 -
noprompt -alias mycerts -file ldapserver.cer

This command adds the LDAP server certificate to the keystore that CAS is "trusting". Outside of deployment configuration of the LDAP authentication handler, this now worked.

When you install CAS in a production environment, SSL certificates will be signed and these problems should not occur. Now, this didn't make the LDAP filter and searchBase configuration any easier, but that's the subject of another post.