Click here to Skip to main content
15,867,704 members
Articles / Programming Languages / Java
Article

CAS May Be Easier in a Production Environment

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
17 Jul 2008CPOL2 min read 14.8K   3  
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.

XML
<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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
CEO Cape Henry Technologies Inc.
United States United States
David is a Java EE professional with 24 years of IT experience. He's developed software from Fortran to Ruby on Rails. He prefers Java. David has managed the development of projects as team leader and solutions architect. He's also managed software development in the US and Pakistan. David recently formed a company Cape Henry Technologies Inc. in Oklahoma and is presently working to establish his corporation in the state of North Carolina. As a solutions provider he thrives on providing solid architecture and then delivering on the implementations of his designs.


David has three primary professional goals:
Use open source solutions to perform Enterprise business implementations
Listen attentively to his clients and clearly understand their needs
Provide only the best quality solutions for his clients

Comments and Discussions

 
-- There are no messages in this forum --