CASifying Liferay Portal EE 6

I CASified a Liferay Portal 6 EE instance on my laptop recently. In this blog I recount the steps.

Only demo deep

CASifying Liferay Portal "for real" would involve using real (or virtual) servers with real host names, SSL certificates, separating CAS and Liferay onto separate servers, and using sensible source control practices for managing your local changes, among a slew of other considerations involved in running serious CAS and Liferay instances. In this blog post, I don't do any of those for-real activities. This is the blog post about getting to a demo-deep example of CASified Liferay running alongside CAS on localhost, and demonstrated using a web browser also running locally on localhost. If any of these elements (CAS, Liferay, browser) are not going to be on localhost, these instructions are insufficient.

(Professional assistance is available, from Unicon, for proper "for-real" installation both of Liferay and of Jasig CAS, and for configuring Liferay to make use of CAS. This blog post certainly should not be confused with that professional assistance.)

Steps I took

Installed Liferay 6 EE

Install Liferay 6 Enterprise Edition.

I have accessed the Enterprise Edition download through Liferay's Customer Portal since Unicon, Inc. is a Liferay Partner. If you haven't licensed the Enterprise Edition, you can probably get an EE trial download and license key by contacting Liferay Inc., or you can download the open source under LGPL Community Edition, both here. (You could also contact Unicon sales about laying hands on Liferay Enterprise Edition, since Unicon is a reseller.)

I downloaded and expanded the Liferay 6 Tomcat 6 bundle. I dropped my developer license key XML file into the "deploy" directory in the resulting exploded directory structure.

I started the bundled Tomcat...

      .../liferay-portal-6.0-ee/tomcat-6.0.29/bin$ ./startup.sh
   

(If you're developing on Windows, that will be startup.bat instead.)

...and logged in as the "test@liferay.com" / "test" default administrative user to sanity check the install.

Then I logged back out.

Installed CAS

I downloaded the CAS server distribution. All the (recent) downloads are available here; I used 3.4.5, the latest GA release as of this writing.

Exploding that tar.gz, I grabbed the cas-server-3.4.5/modules/cas-server-webapp-3.4.5.war, renamed it to cas.war, and dropped it into the webapps directory of the Tomcat instance bundled with Liferay.

I didn't stop Tomcat before, so with Tomcat still running, I hit http://localhost:8080/cas/ in a browser and was helpfully redirected to http://localhost:8080/cas/login .

This default demo CAS webapp authenticates where username equals password, so I tried logging in as "test@liferay.com" with "test@liferay.com" as my password.

CAS helpfully told me I was logged in, though of course not logged in to anything useful, since I didn't try to log in to any particular application.

Configured Liferay to use CAS for authentication

Back to Liferay. I logged in again as that plenipotent "test@liferay.com" user, taking care not to tick the Remember Me checkbox. Recall that the default Liferay password for this user is 'test', not the username-as-password that CAS authenticates by default.

Once logged in, I used the navigation bar along the top to access the Control Panel.

In the control panel, I accessed Settings

Among settings, I accessed Authentication

Within Authentication, I selected CAS

I configured the CAS authentication as shown.

And was sure to Save my changes, with this reassuring confirmation.

Then I signed out, again using the link at the upper right.

Since Liferay is now configured to use CAS, it sent me to the CAS logout URL.

Demonstrated CAS login

First, I manually navigated to http://localhost:8080/, verifying that I'm no longer logged in to Liferay. Then I clicked the Sign In link at the upper right. Note that there's still the username and password login box at left -- if users will exclusively login with CAS, and even if they aren't, some UI cleanup is needed whilst skinning your portal to make it clear where and how users log in with their institutional single sign on. Anyway, clicking the link at the upper right...

...navigated me to the CAS login page. Here I logged in as test@liferay.com. Recall that for this default demo configuration of CAS, CAS authenticates where username equals password.

CAS sends me back to Liferay with a valid Service Ticket, Liferay validates the Service ticket, and I'm logged in as that test@liferay.com test user.

Going beyond demo deep basic CAS configuration

Use real hostnames and separate servers

In the real world, the CAS server, the Liferay portal application, and the web browser should be running on three different boxes. This means that "localhost" will no longer be sufficient to identify the CAS server and the Liferay server. Instead these applications will need to be reachable with real hostnames.

Configure CAS for real

Authenticating users where username equals password is cute, but in the real world you'll need to configure CAS in deployerConfigContext.xml as regards how CAS should validate passwords (or other credentials) against some real backing credential store or validation mechanism. CAS offers many options for how to authenticate user credentials, but what you're really going to do is validate usernames and passwords against LDAP.

Configure Liferay for real

There's many knobs and settings and so forth to configure in Liferay, but one thing you'll want to do is point Liferay at the same LDAP server that CAS is using, so that when CAS authenticates a user, Liferay can then read in that user's attributes. Basic CAS integration provides only the username from CAS to the CASified application. Liferay will be more interesting if it can get more information than just the username. Unless you're going to provision your users into Liferay some other way (manually?), you'll need Liferay to be able to read their attributes just-in-time when they log in.

Use SSL

Since users present their passwords to CAS, CAS should be only available via https://. Liferay should also really be only available via https:// too, since it uses sessions. Cf. Firesheep.

Once you've decided to use SSL, you'll need to procure or create SSL certificates and install them properly in various places. Servers using SSL will need the private key of the certificate installed, and those relying upon the SSL will need to be configured to trust those certificates. Specifically, the Liferay JVM will need to be cofigured to trust the CAS server SSL certificate unless that CAS server SSL certificate is of a nature as to be inherently trusted.

Skin and brand

A healthy layer of skinning and branding on both CAS and Liferay goes a long way to smooth the user authentication experience.

Deeper CAS integration

This blog post demonstrates basic CAS login to Liferay, trivially on localhost and with some directions for doing basic CAS authentication for real.

There's much more to CAS integration than just basic authentication of users via CAS. For example, CAS supports enabling access to end user credentials in CASified applications and n-tier delegated authentication via the CAS "proxy tickets" feature. Neither of these features are achieved with this basic CAS configuration, but they're both achievable and the kind of thing with which Unicon can help you out.