Skip to end of metadata
Go to start of metadata

Göteborgs universitet - Pablo Millet
Doc. Version: 0.1 : 17/7 - 2006 (first release)

All files needed (source, libs, docs. etc) are under the Attachement-tab (See above).

CAS 2 - Oracle SSO/Oracle Portal Installation

The documentation shows how to CASify the SSO part of the OCS.

Guthenburg university uses the whole OCS (Oracle Collaboration Suite)
-- Midtier ( Portal, Mail, Calendar)
-- Infra (OID, SSO)
-- DB (database, mail)

CAS use OID for looking up and validating accounts.
Oracle Portal uses the same OID.

CASifying the Oracle SSO part means that ALL Oracle SSO enabled applications and tools (eg, Oracle Portal, Mail, Calendar) will appear as if they where CAS clients.
Behind the curtains its only the SSO part of the OCS that works with CAS.
A user logged on to CAS should not have to login again when accessing Oracle SSO enabled applications.

This is generally done in three steps;

First we need to install and configure a CAS-server.

Second, we need to "rebuild" the Oracle SSO application so that it becomes a CAS-client. This means all users requesting an Oracle SSO enabled application (Portal, OCS, Portlets etc) will have to pass trough here which results in users being redirected to the CAS-server for authentication.

Third, we need to configure and replace the standard Oracle SSO plugin with our own CASAuthenticator. CASAuthenticator takes care of users coming from the CAS-server and validates its service-tickets. After the validation procedure is done, it passes the user to standard Oracle SSO procedures and hands over responsibility.

1. Purpose of this document

This document describes how to use CAS with Oracle Portal and SSO. This document does not instruct in detail how to install CAS or Oracle Portal/SSO. It is assumed you have basic knowledge about Tomcat, CAS and Oracle products. At the end of this document you'll find some useful links. Otherwise you'll find plenty of howtos out there.

Other versions of Oracle products and CAS have not been tested.

The following is required to be installed and running:

Server 1
- SSL enabled Tomcat version 4 or later.
- CAS version 2.1.1

Server 2
- Oracle Portal version 10.1.2
- Oracle SSO version 10.1.2

2. Install CAS version 2.1.1 (Server1)

Setting up the CAS software is straightforward.
First, download the CAS server and client libraries from:

CAS uses HTTPS, so you must enable this in Tomcat. This can be a bit tricky, but if you follow the links below and the instructions it should work fine. In Apache Tomcat's website you'll find plenty of information and howtos for SSL enabling Tomcat.

2.1 Configure CAS-server (Server1)

See CAS documentation

3. Rebuild Oracle SSO to become a CAS-client (Server2)

This step assumes that you have a CAS server up and running.
We are now going to configure Oracle SSO to use CAS.

3.1 Import CAS-server certificate

You need to import your CAS-servers SSL Certificate into the keystore(s) used by your system.
Example on three different keystores. :

cd %ORACLE_HOME/infra/jre/1.4.2/bin

./keytool -alias -import -file /tmp/certs/ -keystore %ORACLE_HOME/jre/1.4.2/lib/security/cacerts

./keytool -alias -import -file /tmp/certs/ -keystore %ORACLE_HOME/javavm/lib/security/cacerts

./keytool -alias -import -file /tmp/certs/ -keystore %ORACLE_HOME/jdk/jre/lib/security/cacerts

If you are not familiar with javas keytool consider using Portecle (
Portecle is a great tool for managing keystores, certificates import/export, etc.

3.2 Apply the CAS-filter to Oracle SSO application

This step assumes you have done step 3.1.

1. Copy cas-client-java-2.1.1.jar and commons-logging-api.jar to:

2. Copy gu-localplugins.jar to:

3. Edit the Portal SSO applications web.xml to include the CASSimpleFilter servlet filter.
The configuration example below uses and port 8443 for HTTPS. You should change this to suit your own configuration.

Open and edit:

Place the following filter between <web-app> and </web-app> in web.xml.

<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" " app_2_2.dtd">


<!- START CAS -filter ->



    <!- Not implemented in CASSimpleFilter ->



<!- END CAS-filter ->



What does (very simple):
1. If no CAS ServiceTicket (ST) is found in the request it redirects the client to CAS
2. If a ST is found it continues processing the request... meaning that the client will end up on  

From now on requests to any Oracle SSO enabled application (Portal, OCS, Portlets) will be redirected to the CAS-server. (

4. Install and configure the SSO-plugin - CASAuthenticator

Now we need to replace the standard Oracle SSO plugin with our own CASAuthenticator plugin.

This plugin is the key workhorse in CAS-Oracle SSO. Its main purpose is to validate tickets (ST-ServiceTickets) on our CAS-server and enable a valid Oracle SSO-session upon validation for the requesting client/browser.

What does (very simple):
1. Validates the given CAS ServiceTicket (ST).
2. If validation of ST returns success it starts a Oracle SSO session and then hands over the responsibility to standard Oracle SSO. 

4.1. Replace default Oracle SSO with CASAuthenticator

1. Copy:

  • and gu-localplugins.jar to %ORACLE_HOME/sso/plugin/
    (see "Configure CASAuthenticator -" for configuration instructions)
  • cas-client-java-2.1.1.jar to %ORACLE_HOME/sso/lib/

2. Edit: %ORACLE_HOME/sso/conf/

Look for "MediumSecurity_AuthPlugin".

Comment out the default AuthPlugin, like this
#MediumSecurity_AuthPlugin =

and use CASAuthenticator as plugin instead,
MediumSecurity_AuthPlugin =

Save the file and exit... done!

4.2 Configure CASAuthenticator -

# Configuration for ''
# The following logfiles are interesting in your system:
# %ORACLE_HOME/opmn/logs/OC4J~OC4J_SECURITY~default_island~1
# %ORACLE_HOME/sso/log/ssoServer.log
# Pablo Millet
# Goteborgs universitet

# Where CASAuthenticator validates its CAS ServiceTickets
# Notice: It must be '/validate'. Do NOT use 'serviceValidate'

# Some (little) debug info. Set to 'true' or 'false'.

# OID settings
# Function not yet implemented in production env.
# The idea of having this is to have the plugin "doublecheck" if the
# authenticating user really excists in the OID (the directory used by Oracle-SSO).
# Could be handy if the CAS-server authenticates against different LDAP than the
# one Oracle-SSO is using (OID).
# Example:
# 1. User goes to ApplicationX.
# 2. ApplicationX is a CAS-client (SSO-enabled with CAS-server) and redirects the User to CAS-server.
# 3. The User authenticates and CAS-server starts a valid SSO-session for that User.
# 4. CAS-server redirects the User back to ApplicationX with a valid SSO-session.
# Comment:
# Now, if User has access to ApplicationX doesn't necessarily mean that User also has access to Oracle Portal
# although they (Oracle Portal and ApplicationX) are using the same CAS-server.
# The CASAuthenticator should in this case 'recheck' if User has access to Oracle Portal.
# Not tested. Feel free to do so...
# OIDLogin=cn=userWithReadRightsInOID
# OIDPassword=userWithReadRightsInOID_Password
# OIDPort=389
# OIDRootContext="cn=users,dc=dept,dc=gu,dc=net"
# OIDSSL=false

6. Restart...

%ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

Note; The following logfiles are interesting:

  • %ORACLE_HOME/opmn/logs/OC4J~OC4J_SECURITY~default_island~1
  • %ORACLE_HOME/sso/log/ssoServer.log


5. Additional information

  • No labels


  1. How does this work for Oracle SSO to "External Applications"?  To the best of my knowledge it requires the user's password, which CAS does not have access to.

    1. I'm not sure I understand this comment, but...

      - CAS uses the same OID as the Portal (issue clarified and updated in the document).
      - All "external applications/CAS-clients" and their users does exist in the OID.

      1. Doesn't Oracle Portal (or maybe it's just Oracle's SSO) have a concept called an "External Application".  When you integrate an external application into the portal, it would submit the username/password to that application, thereby automatically logging the user in to that application.  I was curious how that would work with a CASified portal.

  2. Yes, Oracle Portal does have a concept called "External Applications", which allows users to log onto external applications. Each application can have a different username and password. But this seems to be a step backwards, as this means that the user's password is stored in the Oracle database using a reversible cypher. I guess this sort of mechanism would still work even if you log in to portal using CAS authentication. But I would have thought single sign on using pure CAS would be much more desirable (if more difficult to achieve) than using Oracle's External Applications.