Apereo CAS - REFEDS MFA Profile with shib-cas-authn3


Collaborate
This blog is managed and hosted on GitHub. If you wish to update the contents of this post or if you have found an inaccuracy and wish to make corrections, we recommend that you please submit a pull request to this repository.

This is a short story on the birth of the shib-cas-authn3 plugin and its newfound support for the REFEDS MFA Profile.

Overview

Though nowadays less so, you may have an IAM deployment composed of both an Apereo CAS Server and a Shibboleth Identity Provider. The original premise for managing such a deployment dates back to days where CAS v3 had [almost] no support for the SAML2 protocol and likewise, the Shibboleth Identity Provider v2 lacked support for the CAS protocol. To accommodate all integration needs, institutions deployed both solutions and then set in pursuit of a way to close the space between the two to provide a seamless user experience.

…and by seamless, I mean:

  • How could one manage SSO sessions between the two platforms?
  • How could one fetch and release attributes to SAML2 SPs?
  • How could one handle single logout?
  • How would the user interface elements behave with regards to SAML2 MDUI?

Viola!

So was born the shib-cas-authn3 plugin. The plugin simply acts as a link between the two platforms, allowing authentication requests from the Shibboleth IdP to be routed “invisibly” to CAS and then back. Conceptually it sits between the two systems, (though physically it lives inside the IdP), and knows how to translate one protocol (SAML2) to another (CAS) and then does it all in reverse order on the trip back to the SAML service provider.

untitled

This is a neat trick because to the SAML2 Service Provider, that fact that authentication from the IdP is delegated to somewhere else is entirely irrelevant. Likewise, the Shibboleth IdP also does not care what external authentication system handles and honors that request. All it cares about is, “I routed the request to X. As long as X gives me back the right stuff, I should be fine to resume”.

Author’s Note

I say nowadays less so because today, the Shibboleth IdP v3 has great support for the CAS protocol and Apereo CAS v5 has native support for the SAML2 Protocol. While “separation of concerns”, “leaving each to its own” and having “boxes and arrows” pointing back and forth and living in perfect harmony in a pretty diagram are excellent conditions to live by, it would be best to consolidate down to one system since the concerns are no longer separate and more so, they tend to cost money and strands of hair quite a bit over time.

Given the right circumstances and support, the Majestic Monolith can be sweet.

Handling REFEDS MFA Profile

So then comes the REFEDS MFA Profile:

This Multi-Factor Authentication (MFA) Profile specifies requirements that an authentication event must meet in order to communicate the usage of MFA. It also defines a SAML authentication context for expressing this…

And:

The MFA Authentication Context can be used by Service Providers to request that Identity Providers perform MFA as defined below and by IdPs to notify SPs that MFA was used.

In more complicated terms, if a SAML SP were to specify https://refeds.org/profile/mfa as the required authentication context, the identity provider would need to translate and find the appropriate MFA solution to execute in order to satisfy that requirement and then reassuringly convey the result back to the SP.

How could we do this with the Shibboleth Identity Provider, Apereo CAS server, and the shib-cas-authn3 plugin all having their bit of fun in the flow?

One Solution

Consider the following starting positions:

  • Since Apereo CAS is ultimately in charge of executing authentication, it would also be the party in charge of executing multifactor authentication.
  • Our strategy for delivering MFA in response to https://refeds.org/profile/mfa would be one backed by Duo Security, easily supported by CAS.

Our task list then would be to find ways to:

  • …communicate the requested authentication context to CAS.
  • …translate the requested authentication context to something CAS would understand as a trigger for Duo Security MFA.
  • …ensure the requested authentication context is satisfied by CAS, before handing off a response to the SP.

Say hello to shib-cas-authn3 v3.2.4.

Collaborate
As of this writing, 3.2.4 is still in beta. Download, deploy, verify and contribute back enhancements as time and DNA permits.

Staring with v3.2.4, the plugin has native support for REFEDS MFA profile. The requested authentication context class that is https://refeds.org/profile/mfa is passed along from the Shibboleth IdP over to this plugin and is then translated to a multifactor authentication strategy supported by and configured in CAS (i.e. Duo Security). The CAS server is notified of the required authentication method via a special authn_method parameter by default. Once a service ticket is issued and plugin begins to validate the service ticket, it will attempt to ensure that the CAS-produced validation payload contains and can successfully assert the required/requested authentication context class.

For additional info on configuring the plugin, please see the project’s README.

So…

I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please feel free to engage and contribute as best as you can.

Misagh Moayyed

Related Posts

Apereo CAS - Microsoft Office 365 SAML2 Integration

Learn how to integrate Microsoft Office 365 with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - HappyFox SAML2 Integration

Learn how to integrate HappyFox with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - Cisco Webex SAML2 Integration

Learn how to integrate Cisco Webex with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - VMware Identity Manager SAML2 Integration

Learn how to integrate VMware Identity Manager with Apereo CAS running as a SAML2 identity provider.

CAS 6.0.0 RC4 Feature Release

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

Apereo CAS - Scripting Multifactor Authentication Triggers

Learn how Apereo CAS may be configured to trigger multifactor authentication using Groovy conditionally decide whether MFA should be triggered for internal vs. external access, taking into account IP ranges, LDAP groups, etc.

Apereo CAS 6.0.x - Building CAS Feature Modules

An overview of how various CAS features modules today can be changed and tested from the perspective of a CAS contributor working on the codebase itself to handle a feature request, bug fix, etc.

CAS 6.0.x Deployment - WAR Overlays

Learn how to configure and build your own CAS deployment via the WAR overlay method, get rich quickly, stay healthy indefinitely and respect family and friends in a few very easy steps.

Apereo CAS - Jib at CAS Docker Images

Learn how you may use Jib, an open-source Java containerizer from Google, and its Gradle plugin to build CAS docker images seamlessly without stepping too deep into scripting Dockerfile commands.

Apereo CAS 6 - Administrative Endpoints & Monitoring

Gain insight into your running Apereo CAS 6 deployment in production. Learn how to monitor and manage the server by using HTTP endpoints and gather metrics to diagnose issues and improve performance.