The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Shibbolize a CAS server

Owned by kefo1760@colorado.edu
Last updated: Mar 03, 2014

We all know what CAS is .. you can read about it on the JASIG CAS pages.

Also was not sure if this belongs in the CAS Wiki or here.. I settled on here for now.

Purpose

There are many ways to integrate CAS and Shibboleth.  The IdPAuthRemoteUser and SSO-CAS Login Handler (s) are examples of integrations where the CAS server is providing the authentication layer to the Identity Provider.  

Here we are concerned about doing basically the opposite.  In our particular environment we did not want to flip the current SSO infrastructure to rely on authentication provided by CAS.  Nor did we want to introduce yet another single sign-on UI to the end user.  The outcome of these two decisions was to "shibbolize" the CAS server.

 

 

How This Works

There are two things that make this work and enhance the ability to throw a Shib-SP in-front of the CAS server. 

  1. CAS internal bindings for Remote User AuthN (Trusted)
  2. Building an internal mechanism for extracting attributes out of the headers of the authn request.

Remote AuthN

Normally you point CAS off to some directory service or user store such as LDAP or DB layer that handles the actual AuthN phase of the sign-on process. Rather than hooking into the DS at this authentication step, in this model we are taking advantage of CAS's Trusted Authentication Handler to make use of the web servers http authentication layer. 

Using "Trusted Auth" gets us in a position to utilize a local previously established single sign-on infrastructure. This is achieved by setting up the CAS server and its accompanying Shib-SP as an Relying Party to our Shibboleth-IdP.

Install and configure the Shibboleth SP as normal.  The CAS server will be using the value found in REMOTE_USER to correlate its internal ticketing mechanics so set the value of your primary identifier accordingly. 

 

Recycle Attributes

Normally CAS would like to access your DS or DB layer to retrieve attributes about the principal that it has just authenticated. In our model we don't want any connections to these outside services rather we want to make use of attributes coming from the Shib-SP in front of CAS.

To do this we modify the deployerConfigContext.xml file in our war-overlay (see CAS wiki) process.  We have to modify the attributeRepository bean to rely on the requestAttributeDao bean which will pull our attributes from the request scope.

Code snippet (modifications to deployerConfigContext.xml)  found here 

Next you will need to add a filter to the CAS applications web.xml file to make the header attributes present in the request scope.  The following additions to web.xml should enable the incoming shibboleth delivered attributes to be accessible to the CAS Attribute DAO.


<filter>
  <filter-name>requestAttributeSourceFilter</filter-name>
  <filter-name>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

...then

<filter-mapping>
  <filter-name>requestAttributeSourceFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>


Shibboleth Specifics

Identity Provider (IdP)

There is nothing specific to the Shibboleth Identity Provider for this setup.  The "CAS Bridge" Relying Party operates just as any known RP does when interacting with the Identity Provider.

Service Provider (SP)

There is nothing specific to the local configuration of the Shibboleth Service Provider to make this work.

The only integration point to be mindful of is the mapping of your incoming attributes to ensure correct correct data translation within the CAS application.  

Apache Locations

To enable both CAS and the Shibboleth-SP to do their jobs with their respective calls, we have to fix up the <Location> blocks in Apache a bit.

It is assumed that all calls to /cas will be proxied to the tomcat instance.

 

    <Location ~ "^/cas/login">
      AuthType shibboleth
      ShibRequestSetting requireSession 1
      ShibUseHeaders On
      Require valid-user 
    </Location>

    <Location ~ "^/cas/serviceValidate">
      AuthType shibboleth
      ShibRequestSetting requireSession 0
      Require shibboleth
    </Location>


    <Location ~ "^/cas/samlValidate">
      AuthType shibboleth
      ShibRequestSetting requireSession 0
      Require shibboleth
    </Location>


    <Location ~ "^/cas/proxy">
      AuthType shibboleth
      ShibRequestSetting requireSession 0
      Require shibboleth
    </Location>


    <Location ~ "^/cas/proxyValidate">
      AuthType shibboleth
      ShibRequestSetting requireSession 0
      Require shibboleth
    </Location>

 

Logout

The idea here is to not rely on the CAS service to maintain the users sso state.  We treat the CAS session strictly as a protocol level session and give it a short lifetime, while relying on the external SSO service to deal with our true SSO session lifetime.

We have further reprogrammed the calls to the /cas/logout location to redirect the user into the Shibboleth-SP logout flow.

Â