Proxying clear-text credentials

Purpose

To enable single sign-on into some legacy application it may be necessary to provide them with the actual cleartext password. While such approach inevitably increases security risk, a number of institutions found it to be a "necessary evil". This page describes a solution by Unicon for Sacramento State.

Architecture

A service may obtain cleartext credentials for an authenticated user by presenting a valid proxy ticket obtained specifically for the CAS cleartext extension service end-point (ClearPass). The specific sequence of calls is shown in a diagram below:

Until the last two steps, only standard CAS protocols are involved. The two steps involve request/response interaction between uPortal and a newly introduced CAS ClearPass service to obtain the cleartext credentials. The request follows the same syntax as standard CAS proxy ticket validation request (typically configured under /proxyValidate path), except that the service endpoint is different (/clearPass in default configuration). Upon receiving the request, ClearPassController ensures that the following validation criteria are met:

1. The proxy ticket was obtained for the URL specifying location of the ClearPass service
2. The proxy is valid according to standard CAS spec
3. The proxy ticket is indeed a proxy ticket, not a service ticket
4. Each member of the proxy chain has been given explicit permission to receive cleartext credentials

Upon successful validation the ClearPass service provides credentials in the following response:

<cas:clearPassResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:clearPassSuccess>
		<cas:credentials>actual_password</cas:credentials>
	</cas:clearPassSuccess>
</cas:clearPassResponse>

If any of the validation steps fail, the error response is returned:

<cas:clearPassResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:clearPassFailure>description of the problem</cas:clearPassFailure>
</cas:clearPassResponse>

Implementation

The code is available in the JA-SIG SVN repository. The reference implementation also includes modifications to uPortal CAS client necessary to take advantage of the new feature.

CAS extensions

_(note: all classes described in this subsection are in the edu.csus.cas.clearpass package)_The CAS login workflow is modified to capture the cleartext password using CacheCredentialsAction. The passwords are stored in an cache implementing CredentialsCache interface. The default cache implementation (CredentialsCacheImpl) uses EhCache.

The ClearPass service endpoint (configured by default under /clearPass) is implemented by ClearPassController class. This service relies on a instance of ClearPassServiceValidator to check if a particular service is allowed to receive cleartext credentials. The default implementation (ClearPassServiceValidatorImpl) simply accepts an explicit list of approvied services (listed by their ProxyReceptor endpoints).

uPortal client extensions

uPortal extensions are implemented by providing an alternative SecurityContext implementation: org.jasig.portal.security.provider.cas.PasswordCachingCasFilteredSecurityContext.