Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

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 with Duo.  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.

 

 

 

 



 

 

 

 

  • No labels