You are viewing the development documentation for the CAS server. The functionality presented here is not released yet. This is a work in progress and will be continually updated as development makes progress. To view the documentation for a specific CAS server version, please choose an appropriate version.
ClearPass: Credential Caching and Replay
To enable single sign-on into some legacy application it may be necessary to provide them with the actual password. While such approach inevitably increases security risk, at times this may be a necessary evil in order to integrate applications with CAS.
ClearPass is turned off by default. No applications will be able to obtain the user credentials unless ClearPass is explicitly turned on by the below configuration.
If you wish to review the configuration for ClearPass via proxying, please see this link instead.
Architecture
CAS is able to issue the credential password directly in the CAS validation response. This previously was handled via a proxy authentication sequence and obtaining a proxy-granting ticket for the ClearPass service and was necessary in order to establish trust between the client application and the CAS server. This document describes the configuration that can be applied in order to receive the credential password as an attribute in the CAS validation response.
In order to successfully establish trust between the
CAS server and the application, private/public key pairs are generated by the client application and then the public key distributed and configured inside CAS. CAS will use the public key to encrypt the credential password and will issue a new attribute <credential> in the validation response, only if the service is authorized to receive it.
Note that the return of the credential is only carried out by the CAS validation response, provided the client
application issues a request to the /p3/serviceValidate endpoint (or /p3/proxyValidate). Other means of returning attributes to CAS, such as SAML1 will not support the additional returning of this value.
Configuration
Register Service
Once you have received the public key from the client application owner, it must be first registered inside the CAS server’s service registry. The service that holds the public key above must also be authorized to receive the password as an attribute for the given attribute release policy of choice.
{
"@class" : "org.jasig.cas.services.RegexRegisteredService",
"serviceId" : "^https://.+",
"name" : "test",
"id" : 1,
"evaluationOrder" : 0,
"attributeReleasePolicy" : {
"@class" : "org.jasig.cas.services.ReturnAllowedAttributeReleasePolicy",
"principalAttributesRepository" : {
"@class" : "org.jasig.cas.authentication.principal.DefaultPrincipalAttributesRepository"
},
"authorizedToReleaseCredentialPassword" : true,
"authorizedToReleaseProxyGrantingTicket" : false
},
"publicKey" : {
"@class" : "org.jasig.cas.services.RegisteredServicePublicKeyImpl",
"location" : "classpath:RSA1024Public.key",
"algorithm" : "RSA"
}
}Decrypt the Password
Once the client application has received the credential attribute in the CAS validation response, it can decrypt it via its own private key. Since the attribute is base64 encoded by default, it needs to be decoded first before
decryption can occur. Here’s a sample code snippet:
final Map<?, ?> attributes = ...
final String encodedPsw = (String) attributes.get("credential");
final PrivateKey privateKey = ...
final Cipher cipher = Cipher.getInstance(privateKey.getAlgorithm());
final byte[] cred64 = decodeBase64ToByteArray(encodedPsw);
cipher.init(Cipher.DECRYPT_MODE, privateKey);
final byte[] cipherData = cipher.doFinal(cred64);
return new String(cipherData);Components
-
RegisteredServiceCipherExecutorDefines how to encrypt data based on registered service’s public key, etc. -
DefaultRegisteredServiceCipherExecutorA default implementation of theRegisteredServiceCipherExecutorthat will use the service’s public key to initialize the cipher to encrypt and encode the value. All results are converted to base-64. -
CasAttributeEncoderParent component that defines how a CAS attribute is to be encoded and signed in the CAS validation response. -
DefaultCasAttributeEncoderThe default implementation of the attribute encoder that will use a per-service key-pair to encrypt. It will attempt to query the collection of attributes that resolved to determine which attributes can be encoded. Attributes will be encoded via aRegisteredServiceCipherExecutor.
<bean id="cas3ServiceSuccessView"
class="org.jasig.cas.web.view.Cas30ResponseView"
c:view-ref="cas3JstlSuccessView"
p:successResponse="true"
p:servicesManager-ref="servicesManager"
p:casAttributeEncoder-ref="casAttributeEncoder" />
<bean id="casRegisteredServiceCipherExecutor"
class="org.jasig.cas.services.DefaultRegisteredServiceCipherExecutor" />
<bean id="casAttributeEncoder"
class="org.jasig.cas.authentication.support.DefaultCasAttributeEncoder"
c:servicesManager-ref="servicesManager"
c:cipherExecutor-ref="casRegisteredServiceCipherExecutor" />