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:
- The proxy ticket was obtained for the URL specifying location of the ClearPass service
- The proxy is valid according to standard CAS spec
- The proxy ticket is indeed a proxy ticket, not a service ticket
- 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.