You are here

CAS and Luminis 4 - using external/central CAS

Submitted by ToddTrann on Fri, 09/04/2009 - 11:19

At the University of Saskatchewan, we use CAS for authentication in many of our web-based applications.  These applications use a central CAS, not the CAS bundled with Luminis.  However, we want people to be able to get from the portal into any web-based CAS-protected application seamlessly. 

We have this set up and running in production.  Here are (hopefully all) the steps we followed to do so:
 

Prerequisite Installations

  • Install the CAS package into Luminis following Sungard's instructions ("Yale CAS Installation and Configuration").
  • Modify your central CAS so it trusts third party servers.  See http://www.usask.ca/docs/cas/trusting.html
     

Configure CAS Support in Luminis 4

On the Luminis 4 resource tier set the following in configman:

configman -s remotesessioneventlistener.0.url https://resourcetier.your.edu/cas/sessionEventNotify
configman -s cas.fqn resourcetier.your.edu
configman -s com.pipeline.cas.ExternalSessionCache.sessionEventNotification remote-provider

For parallel deployment only:
  configman -s fos.server.cookie.domain resourcetier.your.edu -c site -h
  configman -s fos.server.secure.cookie.domain resourcetier.your.edu -c site -h

Note that we are changing the cookie domain for the web server that is running on the resource tier in parallel deployment.  This assumes, however, that you are not using this web server to actually serve up content to the users (which it shouldn't be).

On the resource tier, in /opt/pipeline/webapps/luminis/cas, verify that login-cp.jsp and logout-cp.jsp say the virtual portal domain name, not resource tier host name.

Restart luminis on resource tier and web servers.

You can now test CAS as follows:

When you do that you should see a message: "You have been logged in successfully"

Configure Trust between CAS and Luminis

On the Luminis web servers, set a domain cookie when people login to luminis and remove it when they logout.  We call ours portal.login.date, and this is used so that central CAS knows when to check Luminis CAS for a valid ticket or not. 

On the central CAS server, setup the cas.your.edu virtual host in apache to trust Luminis 4, i.e:

CASLoginURL https://resourcetier.your.edu/cas/login
CASValidateURL https://resourcetier.your.edu/cas/serviceValidate
CASAllowWildcardCert On
CASValidateServer On
CASCookiePath /var/run/mod_auth_cas_resourcetier/
 

To test the trust, login to the portal (but not central CAS) then go to an application that uses CAS.

Luminis Version:

Comments

I thought we had docs online for trusting CAS - sad that you found it and not me, but I've revised my post to reflect this, thanks!! 

Yes, this is for Luminis 4, that's what we're on.

Todd

Todd,

In this approach, are the user passwords still stored in the Luminis Secret store? Also, what version is the central/external CAS that you are using on your campus? Is it CAS 3? We have been looking into the Sungard UDC CAS model that uses BannerValidate. For that CAS3 is a pre-requisite.

Sorry for late reply, sometimes I miss reading the noficiations from LumDev (my fault, not LumDev's)

In this approach, are the user passwords still stored in the Luminis Secret store?

Yes, that is how the user authenticates locally.  Note that we are not getting the users into Luminis once they're in CAS, we're doing the opposite, getting users into CAS once they're in Luminis

Also, what version is the central/external CAS that you are using on your campus? Is it CAS 3?

Yes, CAS3.  I think the version is 3.1.

I assume this is a configman setting but I'm not completely sure if that is the case. Could you enlighten me as to how and where one would configure a domain cookie?

Thanks

Erik

When users log into the U of S portal, they do not go to /cp/home/login.  Instead, their form is submitted to /cp/home/CaptureLogin which is a custom servlet based on the work of Bob from Langara.  This servlet does two things:

- compare password entered to our "temporary password" database, and if it matches, then send the student over to our identity management system to set up password recovery and set a permanent password

- set a domain cookie to indicate that they have logged into the portal (used for CAS)

Then of course on logout, we clear this cookie.

Todd

Perfect, Now I have a better idea of what I need to do.

Erik