CAS 4.2 with Duo MFA Technical Considerations

Purpose

This document will provide an understanding of the decisions, implications and details of IET's implementation of CAS 4.2 with Duo MFA.

Background and Considerations

At the time IET was given the task of implementing Duo MFA with CAS, the current CAS production server was running with release version 3.5.x.  The most recent stable release when design considerations began was 4.1.x, with 4.2.x release nearing.  None of these versions, or any in between, had any out-of-the-box MFA implementation that could be used to implement second factor authentication with Duo.  We found that Unicon does provide a Duo CAS Plugin that was compatible with 3.6.x, but not with any version above that.  This plugin is the basis of the Duo MFA implementation that is partially implemented in 4.2.x and should be fully realized in a future 5.0.x release.  It was decided that we would implement Duo MFA into the 4.2.x release by creating a custom login flow to accommodate CAS clients that required it.  The following factors went into this determination:

• 4.2.x was scheduled to be completed to meet our timeline
• Part of the code needed to implement is present in 4.2.x
• Upgrade the current CAS servers to more functional stable release
• 4.2.x uses Hazelcast for distributed ticket registry, an improvement over existing EHCache
• 4.2.x includes a Sessions Management feature for removing offending TGTs
• 4.2.x includes a Service Registry Management app for adding,editing,deleting allowed services

Implementation

Service Registry

IET was asked to make the Duo MFA be applicable to only services that require it.  In order to meet this requirement we needed to create and use a service registry within CAS that allows us to mark which services are required to use Duo.  This is partially implemented as of 4.2.x with the Required Handlers field of the default service registry, but would not be usable until full MFA login flow is implemented in a future release.  A decision was made to extend the service definition in CAS to include a Requires Duo field.  This gives us a clear delineation of which services require the use of Duo by both system admins tasked to maintain the service registry, and in the CAS login flow.  We were not able to implement this change with a standard Maven Overlay.  The code needed to be extended was not designed by project owners to be easily extended or replaced using an overlay.  Secondly this additional code is needed in both CAS and the CAS Management application.  Making these changes as an overlay would mean duplicating code between the two builds.  We made the changes directly to the CAS source code so that each application is then able to use the Maven Overlay to customize and build each application.  Instructions for obtaining CAS source and applying our patch can be found /wiki/spaces/~tsschmidt/pages/251397685.  

CAS Server

CAS login flow was customized to present a Duo Authentication challenge after a successful login with username and password, onlly if the service being accessed was marked as Requires Duo in the service registry.  This was implemented by using a Maven Overlay to replace the default login-webflow.xml definition.  A new view state was added to display the Duo Authentication challenge to the user and is called as a subflow state from the login flow after a valid login. An action state was added before displaying the Duo challenge to ensure the user attempting login has a registered device.  If the user is not enrolled in Duo or does not have a registered device, a TGT is created which allows them to be Single Signed On to any other service that does not require Duo, but is denied access to the requested service.  Instead the user is presented with a link to a knowledge base article on how to enroll in Duo.  This flow is visualized in the following diagram:

Provisioning

The knowledge base article link presented to users without a registered device, will direct them to Computing Accounts.  Here it will be determined if they are eligible to register a device in Duo.  At this point then the will be directed to a Duo frame that will allow them to register and verify a device.  After this is done they will be able to login to the original service they attempted to access.  The following use case sequence demonstrates this activity:

Each colored box above represents a redirect of the user.

Limitations

Single Sign On

With the current state of MFA in CAS, and the decisions we have outlined above, single sign on can appear to behave a bit differently then might be expected.  The state of 4.2.x CAS and our solution does not allow us to store Duo credentials alongside the currently used username/password credentials.  When a user signs into a Duo protected site, they will not be challenged again for any other CAS protected site that does not require Duo.  However if they attempt to access a Duo protected site that resides behind a different CAS client, they will be challenged to authenticate with Duo again.  Future releases of CAS will have the ability to store multiple authentication results in the TGT that will allow us to change this behavior.  In order meet our given timeline and to not guess the direction or duplicate the work of CAS contributors, we did not attempt to implement this feature.  

Duo Availability

Duo is an external service outside the control of IET.   There can be any number of circumstances beyond our control that could render Duo unavailable.  The preauth check outlined in the flow above is used not only determine a users status, but if the service is available and in a usable state.  It has been determined that we will take a fail open approach in instances when Duo is not available.  This means then if a user has successfully signed in against LDAP, they will bypass the Duo challenge and be redirected to the requested service in those situations.  We have included the ability to change this behavior to a fail closed approach, which will deny users access to any Duo protected site if the service is not available. 

Duo Specific 

General MFA is not supported by our solution.  This implementation requires that second factor authentication is provided through Duo and is not extendable to other providers easily.  The majority of our CAS clients are university entities and most likely would not procure separate MFA solutions.  This means that efforts taken to implement Duo would need to be duplicated to add or switch second factor providers.

Enhancements

UI

We have taken the opportunity with this project to upgrade the look and feel of the CAS login page to be more in line with current university branding.   The new page will also be cleaner and more responsive to different screen sizes on traditional and mobile screens.  We are working with communications to ensure the layout and language of the page is effective and universal.  We realize changes to a high profile service will be noticed and questioned, and we are taking steps to inform as many as possible of the impending change.

Service Registry

A registry of allowed services will be implemented and used to determine if the referring CAS client is allowed to authenticate against our server.  Besides allowing us to determine if a service requires Duo, we are now able to grant or deny access to the CAS server based on the requested service.  A CAS client for instance that becomes compromised or is sending an unusual amount of requests that threatens availability of the service, can be disabled and their requests ignored until the situation is resolved.  

Session Management 

 We now have the ability to query the CAS server for all active TGTs.  This allows us to find and remove tickets that may be causing problems or have been created by some system or client request error.  We can also ensure that a specific users credentials are not active and immediately revoked at the server level.

Management Application

Administration of the service registry and the sessions is facilitated through a separate web application that is secured through CAS and limited to specified users.   The management application is a new feature of the 4.2.x release. The default implementation only includes service registry management.  The session management is a feature of the CAS server that by default is restricted to those that have access to the localhost serving the application.  We have implemented the session management to be a part of the management application.  This gives us two benefits over the CAS default.  First, the session management is now accessible from locations outside the CAS host machine.  This allows us to put further restrictions on who can access this feature, such as belonging to a LDAP group with permissions.  Secondly, since we cluster three CAS servers to meet our load requirements, this gives us one place to view sessions on all three servers.  Service registry entries a stored in files in JSON format.  The CAS server and management app periodically poll the directory these files are located at to load changes.  We have extended the functionality of the management application to use a two phase commit process to commit and publish changes to services.  We used Git repositories to implement this feature.  This provides a record of changes made to services, and the ability to audit who made changes and for what reasons.  It also provides the ability to restore the service registry to any past state.

Conclusions

While we have designed and implemented a robust solution of adding Duo MFA to our CAS login, there are two factors to consider for the future.  First, there is ongoing efforts in IET to upgrade our Shibboleth server to version 3.2.1 with Duo MFA support.  This version includes the ability to respond to both CAS and SAML protocols.  This has the implications that Shibboleth could respond to CAS clients, and a standalone CAS server may not be needed.   Details on this effort can be found /wiki/spaces/~tsschmidt/pages/249823473.  Secondly, future versions of CAS are slated to have full MFA support.  This would allow us to address the limitations that are outlined in this document.  It would also mean that we could simplify our build process by no longer needing to apply our own patch to CAS source.