ClearPass: Credential Caching and Replay

To enable single sign-on into some legacy applications 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.

Usage Warning!

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. Think VERY CAREFULLY before turning on this feature, as it MUST be the last resort in getting an integration to work...maybe not even then.

Overview

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.

Also note that CAS by default attempts to encrypt the cached credential in memory via its own pre-generated keys for signing and encryption. When the attribute is to be released to the application, CAS will internally decode the credential first and then will attempt to encrypt it again this time using the service’s public key credentials.

ClearPass via Proxying!

CAS no longer supports retrieving the credential via the proxying mechanism. Applications that intend to obtain the credential need to be updated to account for the following approach described here.

Cache Credential

Enable the caching and capturing of the credential in CAS properties.

The following settings and properties are available from the CAS configuration catalog:

The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting is not strictly necessary in the end-user CAS configuration, because a default value may be assigned or the feature in question may not be immediately intended for use. You may want to own the setting and update it assigned value, assuming the intended feature controlled by the setting is utilized.

  • cas.clearpass.crypto.encryption.key=
  • The encryption key is a JWT whose length is defined by the signing key size setting.

  • cas.clearpass.crypto.signing.key=
  • The signing key is a JWT whose length is defined by the signing key size setting.

    The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.

  • cas.clearpass.cache-credential=false
  • Enable clearpass and allow CAS to cache credentials.

  • cas.clearpass.crypto.alg=
  • The signing/encryption algorithm to use.

  • cas.clearpass.crypto.enabled=true
  • Whether crypto operations are enabled.

  • cas.clearpass.crypto.encryption.key-size=512
  • The encryption key size.

  • cas.clearpass.crypto.signing.key-size=512
  • The signing key size.

  • cas.clearpass.crypto.strategy-type=ENCRYPT_AND_SIGN
  • Control the cipher sequence of operations. The accepted values are:

    • ENCRYPT_AND_SIGN: Encrypt the value first, and then sign.
    • SIGN_AND_ENCRYPT: Sign the value first, and then encrypt.