OutlineCAS can be integrated with the Shibboleth federated SSO platform by a couple different strategies.
Designate CAS the Authentication Provider for Shib IDP
The following instructions describe how to set up a recent CAS server (e.g. 3.3.x) to serve as the authentication provider for the Shibboleth 2.x IDP. With such a setup, when user is routed to the Shib IDP, one of two things will happen:
CAS-Shib IDP integration in this manner is well supported and straightforward to implement.
Before you begin, you should give some thought to configuration management issues. Although the steps below could be implemented by simply copying files and editing configuration XML in the deployed IDP war file directory, the Middleware Group at Virginia Tech has found it much easier to develop an ant-based build process that overlays configuration files on top of the ant-based IDP build. That has worked out well for us and has greatly eased the process by which configuration changes are tested and deployed.
Include CAS Client Libraries in IDP Deployable
Download the latest Jasig Java CAS Client Release and modify the IDP war deployable such that the following jars are included in the ./lib installer folder, then run ./install.sh to build and deploy with these files:
Note that commons-logging is, in fact, required since Shib uses slf4j for logging. If in the future the CAS client switches to slf4j, commons-logging will not be needed.
Modify IDP Deployable web.xml
Add the following XML blocks to the web.xml file for the IDP war deployable. Replace Ant placeholder properties with values appropriate to your environment.
The following is defined by default in the IDP web.xml, but it is included here for completeness since it is required for CAS integration.
Restart the IDP servlet and/or servlet container and verify that CAS authentication is used. The TestShib Service Provider is one convenient test option.
The CASShib project attempts to ease the deployment burden to Shibbolize services that have an existing investment in CAS.
CAS-Shib Integration Facilitates InCommon Assurance
We recently participated in some InCommon Assurance testing with the CILogon service and our integration scenario is both interesting and novel. In particular we were able to quickly develop an integration strategy to assert InCommon Silver for strong authentication at CAS. The high-level integration strategy follows and assumes that CAS is the authentication provider for Shib via the remote authentication mechanism discussed above:
It's important to note that the
We leveraged some existing plumbing to generate the synthetic eduPersonAssurance attribute at CAS. We already calculate an LOA attribute based on the credential type authenticated at CAS. We accept both username/password authentication https://auth.vt.edu and X.509 authentication via certificates that live exclusively on an Aladdin eToken https://auth.vt.edu?pdc=1. It is planned that special classes of eToken credentials will be compliant with InCommon Silver, and we would leverage a similar calculation to LOA to populate the eduPersonAssurance attribute with the Silver URI,
The core integration between CAS and Shib happens with a custom servlet filter, AssertionAttributeAuthenticationMethodFilter, that performs a single function: extract the eduPersonAssurance attribute from the CAS assertion and set the
Note the use of the SAML protocol for CAS ticket validation, which is required for release of the eduPersonAssurance attribute to Shib. The filter is fairly flexible, allowing the use of a either an authentication or principal attribute. We chose eduPersonAssurance since it seemed most appropriate for this use case.
The Shibboleth authentication handler configuration needed to be changed to send users to CAS if InCommon silver or bronze are requested by the SP.
Shibboleth IDP External Authentication via CAS plugin
This is a Shibboleth IDP external authentication plugin that delegates the authentication to the Central Authentication Server. The biggest advantage of using this component over the plain