Page Comparison

...

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 attribute 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.

...