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.

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

Cache Credentials

1
2
3
<util:list id="authenticationMetadataPopulators">
    <ref bean="cacheCredentialsMetaDataPopulator" />
</util:list>

Create Public/Private Keys

1
2
3
4
openssl genrsa -out private.key 1024
openssl rsa -pubout -in private.key -out public.key -inform PEM -outform DER
openssl pkcs8 -topk8 -inform PER -outform DER -nocrypt -in private.key -out private.p8
openssl req -new -x509 -key private.key -out x509.pem -days 365

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  "@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:

1
2
3
4
5
6
7
8
9
10
11
final Map<?, ?> attributes = ...
final String encodedPsw = (String) attributes.get("credential");

/* Use the private.key file generated above. */
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);