Shibbolizing Apereo CAS


This is a brief overview that explains how to shibbolize the Apereo CAS server; that is to let the CAS server be protected by an instance of the Shibboleth Service Provider, where the SP is then tasked to delegate authentication requests to a remote SAML2 identity provider. The entire SAML2 interaction is kept between the SP and the IdP while CAS on the return trip eventually picks up the user profile from the SP in form of special headers, etc.

But…Why?

This is a very elaborate setup, yes. The goal originally was to let CAS simply and directly delegate authentication requests to the SAML2 identity provider. This can very easily be done, except that in this particular case the SAML2 identity provider only supported a very specific and rather complicated variation of the SAML2 protocol, whose support is absent in CAS today. Convincing the identity provider to provide support for the more-mainstream SAML2 WebSSO Browser Profile led to a path riddled with uncertainties. After further analysis, we came to the conclusion that implementing built-in support for the IdP-supported SAML2 profile variation in CAS is unnecessarily complicated, needlessly expensive and possibly soon-to-be obsolete.

Of course, it is certainly possible to do. If you have to ask: all you need is love, coffee and access to decent hair conditioning products.

So the path to least resistance turned out to be a deployment with a few additional components and with a clear separation of boundaries. Thanks to Docker and outstanding help from colleagues, we managed to get this working.

Read on.

How

Starting out with a proof of concept, we came up with a dockerized deployment as such:

Shy of a pretty sequence diagram, here’s how the interaction between the above components works:

  1. Client browser attempts to access the sample CASified PHP application.
  2. Requests to the CAS /login endpoint are intercepted by the SP and Apache.
  3. The SP, configured to speak the special SAML2 protocol, routes the request to the IdP.
  4. The IdP accepts user credentials and posts back the response to the SP.
  5. The SP passes the response back to the CAS /login endpoint.
  6. CAS is configured to trust the response and proceeds to extract user profile data from the request.
  7. CAS proceeds to issue an ST for the PHP application that initiated the request.
  8. Having received and validated the ST, user is granted entry to the PHP application.

CAS

We also applied a few minor patches to CAS:

  • Ensure CAS could easily lend itself to be intercepted by Apache when running in embedded mode.
  • Ensure user profile data can correctly be recognized from the SP.
  • Ensure attributes collected from the SP can be merged and combined with CAS’ own, in cases where supplementary attribute sources are directly defined inside CAS.

The trusted authentication piece is already handled by CAS today.

How Do I…?

All patches are contributed back to the CAS project. You are most welcome! :-)

So…

Special thanks to @jtgasper3 for beautifully cementing the deployment foundation of each component via Docker, big kudos to @scalding for making the integration magic work seamlessly and to @apetro for having previously worked on the trusted authentication piece in CAS.

Of course, I intend to take all the credit.

Misagh Moayyed

Related Posts

CAS 6.1.0 RC4 Feature Release

...in which I present an overview of CAS 6.1.0 RC4 release.

Apereo CAS - Multifactor Provider Selection

Learn how to configure CAS to integrate with and use multiple multifactor providers at the same time. This post also reveals a few super secret and yet open-source strategies one may use to select appropriate providers for authentication attempts, whether automatically or based on a menu.

Apereo CAS - Dockerized Hazelcast Deployments

Learn how to run CAS backed by a Hazelcast cluster in Docker containers and take advantage of the Hazelcast management center to monitor and observer cluster members.

Apereo CAS - Configuration Security w/ Jasypt

Learn how to secure CAS configuration settings and properties with Jasypt.

CAS 6.1.0 RC3 Feature Release

...in which I present an overview of CAS 6.1.0 RC3 release.

Apereo CAS - Webflow Decorations

Learn how you may decorate the Apereo CAS login webflow to inject data pieces and objects into the processing engine for display purposes, peace on earth and prosperity of all mankind, etc. Mainly, etc.

Apereo CAS - SAML2 Metadata Query Protocol

Learn how you may configure Apereo CAS to fetch and validate SAML2 metadata for service providers from InCommon's MDQ server using the metadata query protocol.

Saving Time is Time Consuming

May you live in the best of times. May you live in the startup times.

Apereo CAS 6.1.x - Credential Caching & Proxy AuthN

Learn how you may configure Apereo CAS to capture and cache the credential's password and the proxy-granting ticket in proxy authentication scenarios, pass them along to applications as regular attributes/claims. We will also be reviewing a handful of attribute release strategies that specifically affect authentication attributes, conveying metadata about the authentication event itself.

Apereo CAS 6.1.x - Attribute Repositories w/ Person Directory

An overview of CAS attribute repositories and strategies on how to fetch attributes from a variety of sources in addition to the authentication source, merge and combine attributes from said sources to ultimately release them to applications with a fair bit of caching.