CAS Impersonation

This document outlines a proposed implementation to provide an impersonation feature in CAS for service owners to test their applications. 

Impersonation has been implemented as an additional webflow separate from CAS login. The path to this flow is HOST/cas/impersonate.

Here is a screenshot of the impersonate flow view.

An additional field has been added that is used to enter the user that should be impersonated, and the user doing the impersonation enters their own LDAP credentials like any other CAS Login.

On a successful login A TGT will be created for the user that logged in, and this will be a standard SSO session.  The ST that is created through the /impersonate though will return the user id entered in the Impersonate: field of the form.

Any subsequent ST request that comes through /impersonate for this same TGT will return the impersonation when validated.

 Any subsequent ST request that comes through /login for this same TGT will return the user validated against LDAP doing the impersonation.

A limitation currently is that any SSO session started with /login then can not  be used for /impersonate since the impersonation will not be set in the credentials.

For obvious security reasons this feature should only be turned on against test servers.  To allow a server to do impersonation set this flag in cas.properties

cas.allowed.to.impersonate=true

This field should only be present on test servers and the default value is set to false.  If impersonation is not activated then accessing cas/impersonate will return CAS Unavailable message.

The second step to allow impersonation is to grant a specific user permissions to impersonate specific services.  This is down by adding an entry to /ucd/local/cas/ext-conf/impersonators.json.

Here is an example of the file:

If a user attempts impersonation and they are not in the file, or the service they attempt to impersonate is not in their list of services than they will receive the CAS Unavailable screen.

This file can be edited and on a running system and the changes will be loaded immediately. 

If a service requires Duo to login, then it will also require Duo to impersonate.  There was thought of making impersonate require Duo for any service, but that is not implemented for now.