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