Redis Ticket Registry

Redis integration is enabled by including the following dependency in the WAR overlay:

<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-redis-ticket-registry</artifactId>
    <version>${cas.version}</version>
</dependency>

implementation "org.apereo.cas:cas-server-support-redis-ticket-registry:${project.'cas.version'}"

dependencyManagement {
    imports {
        mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
    }
}

dependencies {
    implementation "org.apereo.cas:cas-server-support-redis-ticket-registry"
}

dependencies {
    /*
    The following platform references should be included automatically and are listed here for reference only.
            
    implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
    implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
    */

    implementation "org.apereo.cas:cas-server-support-redis-ticket-registry"
}

This registry stores tickets in one or more Redis instances. CAS presents and uses Redis as a key/value store that accepts String keys and CAS ticket objects as values. The key is started with CAS_TICKET:.

The Redis ticket registry supports Redis Sentinel, which provides high availability for Redis. In practical terms this means that using Sentinel you can create a Redis deployment that resists without human intervention to certain kind of failures. Redis Sentinel also provides other collateral tasks such as monitoring, notifications and acts as a configuration provider for clients.

Configuration

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 may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.}

cas.ticket.registry.redis.crypto.encryption.key=

The encryption key. The encryption key by default and unless specified otherwise must be randomly-generated string whose length is defined by the encryption key size setting.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value. The only possible exception to this rule is when naming actuator endpoints; The name of the actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.encryption.key=...

This is the most common form of property configuration that is recognized by CAS, regardless of the actual property source, which might in fact be managed separately outside the CAS environment, by another system or cloud framework.

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          encryption: 
            key: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.encryption.key="..." -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory. Note the placement of the system property which must be specified before the CAS web application is launched.

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENCRYPTION_KEY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.encryption.key="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.signing.key=

The signing key is a JWT whose length is defined by the signing key size setting.

org.apereo.cas.configuration.model.core.util.SigningJwtCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.signing.key=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          signing: 
            key: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.signing.key="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_SIGNING_KEY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.signing.key="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].host=

Server's host address.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].host=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            host: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].host="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_HOST="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].host="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].port=

Server's port number.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].port=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            port: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].port="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_PORT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].port="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].replica-of=

Set the id of the master node.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].replica-of=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            replica-of: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].replica-of="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_REPLICA_OF="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].replica-of="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].type=

Indicate the type/role of this node. Accepted values are: MASTER, SLAVE.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].type=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            type: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].type="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_TYPE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].type="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.password=

The cluster connection's password.

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.password=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.enabled=false

Enable the pooling configuration.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.enabled=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.sentinel.master=

Name of Redis server.

org.apereo.cas.configuration.model.support.redis.RedisSentinelProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.sentinel.master=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        sentinel: 
          master: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.sentinel.master="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_SENTINEL_MASTER="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.sentinel.master="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.database=0

Database index used by the connection factory.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.database=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        database: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.database="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_DATABASE="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.database="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.enabled=true

Whether the module is enabled or not, defaults to true.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.enabled=true

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        enabled: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.enabled="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_ENABLED="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.enabled="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.host=localhost

Redis server host.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.host=localhost

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        host: "localhost"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.host="localhost" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_HOST="localhost"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.host="localhost"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.password=

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.password=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.port=6379

Redis server port.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.port=6379

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        port: "6379"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.port="6379" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_PORT="6379"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.port="6379"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

# The encryption key.
# cas.ticket.registry.redis.crypto.encryption.key=

# The signing key is a JWT whose length is defined by the signing key size setting.
# cas.ticket.registry.redis.crypto.signing.key=

# Server's host address.
# cas.ticket.registry.redis.cluster.nodes[0].host=

# Server's port number.
# cas.ticket.registry.redis.cluster.nodes[0].port=

# Set the id of the master node.
# cas.ticket.registry.redis.cluster.nodes[0].replica-of=

# Indicate the type/role of this node.
# cas.ticket.registry.redis.cluster.nodes[0].type=

# The cluster connection's password.
# cas.ticket.registry.redis.cluster.password=

# Enable the pooling configuration.
# cas.ticket.registry.redis.pool.enabled=false

# Name of Redis server.
# cas.ticket.registry.redis.sentinel.master=

# Database index used by the connection factory.
# cas.ticket.registry.redis.database=0

# Whether the module is enabled or not, defaults to true.
# cas.ticket.registry.redis.enabled=true

# Redis server host.
# cas.ticket.registry.redis.host=localhost

# Login password of the redis server.
# cas.ticket.registry.redis.password=

# Redis server port.
# cas.ticket.registry.redis.port=6379

_{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. You should only include this field in your
configuration if you need to modify the default value.}

cas.ticket.registry.redis.crypto.alg=AES

The signing/encryption algorithm to use.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedSigningJwtCryptographyProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.alg=AES

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          alg: "AES"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.alg="AES" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ALG="AES"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.alg="AES"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.enabled=true

Whether crypto operations are enabled.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedSigningJwtCryptographyProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.enabled=true

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          enabled: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.enabled="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENABLED="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.enabled="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.encryption.key-size=16

Encryption key size.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.encryption.key-size=16

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          encryption: 
            key-size: "16"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.encryption.key-size="16" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENCRYPTION_KEY_SIZE="16"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.encryption.key-size="16"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.signing.key-size=512

The signing key size.

org.apereo.cas.configuration.model.core.util.SigningJwtCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.signing.key-size=512

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          signing: 
            key-size: "512"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.signing.key-size="512" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_SIGNING_KEY_SIZE="512"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.signing.key-size="512"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.adaptive-topology-refresh=false

Whether adaptive topology refreshing using all available refresh triggers should be used.

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.adaptive-topology-refresh=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          adaptive-topology-refresh: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.adaptive-topology-refresh="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_ADAPTIVE_TOPOLOGY_REFRESH="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.adaptive-topology-refresh="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.dynamic-refresh-sources=true

Whether to discover and query all cluster nodes for obtaining the cluster topology. When set to false, only the initial seed nodes are used as sources for topology discovery.

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.dynamic-refresh-sources=true

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          dynamic-refresh-sources: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.dynamic-refresh-sources="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_DYNAMIC_REFRESH_SOURCES="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.dynamic-refresh-sources="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.max-redirects=0

The max number of redirects to follow.

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.max-redirects=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          max-redirects: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.max-redirects="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_MAX_REDIRECTS="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.max-redirects="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes=

List of nodes available in the redis cluster.

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].id=

Identifier of this node.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].id=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            id: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].id="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_ID="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].id="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.nodes[0].name=

Name of this node.

org.apereo.cas.configuration.model.support.redis.RedisClusterNodeProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.nodes[0].name=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          nodes[0]: 
            name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.nodes[0].name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_NODES[0]_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.nodes[0].name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.cluster.topology-refresh-period=

Enables periodic refresh of cluster topology and sets the refresh period.

This settings supports the java.time.Duration syntax ^[?].

org.apereo.cas.configuration.model.support.redis.RedisClusterProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.cluster.topology-refresh-period=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        cluster: 
          topology-refresh-period: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.cluster.topology-refresh-period="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CLUSTER_TOPOLOGY_REFRESH_PERIOD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.cluster.topology-refresh-period="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.fairness=false

Returns whether or not the pool serves threads waiting to borrow objects fairly. True means that waiting threads are served as if waiting in a FIFO queue.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.fairness=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          fairness: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.fairness="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_FAIRNESS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.fairness="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.lifo=true

Returns whether the pool has LIFO (last in, first out) behaviour with respect to idle objects - always returning the most recently used object from the pool, or as a FIFO (first in, first out) queue, where the pool always returns the oldest object in the idle object pool.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.lifo=true

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          lifo: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.lifo="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_LIFO="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.lifo="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.max-active=8

Max number of connections that can be allocated by the pool at a given time. Use a negative value for no limit.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.max-active=8

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          max-active: "8"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.max-active="8" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_MAX_ACTIVE="8"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.max-active="8"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.max-idle=8

Max number of "idle" connections in the pool. Use a negative value to indicate an unlimited number of idle connections.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.max-idle=8

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          max-idle: "8"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.max-idle="8" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_MAX_IDLE="8"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.max-idle="8"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.max-wait=-1

Maximum amount of time (in milliseconds) a connection allocation should block before throwing an exception when the pool is exhausted. Use a negative value to block indefinitely.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.max-wait=-1

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          max-wait: "-1"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.max-wait="-1" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_MAX_WAIT="-1"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.max-wait="-1"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.min-evictable-idle-time-millis=0

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.min-evictable-idle-time-millis=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          min-evictable-idle-time-millis: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.min-evictable-idle-time-millis="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_MIN_EVICTABLE_IDLE_TIME_MILLIS="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.min-evictable-idle-time-millis="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.min-idle=0

Target for the minimum number of idle connections to maintain in the pool. This setting only has an effect if it is positive.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.min-idle=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          min-idle: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.min-idle="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_MIN_IDLE="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.min-idle="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.num-tests-per-eviction-run=0

Sets the maximum number of objects to examine during each run (if any) of the idle object evictor thread. When positive, the number of tests performed for a run will be the minimum of the configured value and the number of idle instances in the pool. When negative, the number of tests performed will be ceil(getNumIdle()/ abs(getNumTestsPerEvictionRun())) which means that when the value is -n roughly one nth of the idle objects will be tested per run.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.num-tests-per-eviction-run=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          num-tests-per-eviction-run: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.num-tests-per-eviction-run="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_NUM_TESTS_PER_EVICTION_RUN="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.num-tests-per-eviction-run="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.soft-min-evictable-idle-time-millis=0

Sets the minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any - see setTimeBetweenEvictionRunsMillis(long)), with the extra condition that at least minIdle object instances remain in the pool. This setting is overridden by getMinEvictableIdleTimeMillis() (that is, if getMinEvictableIdleTimeMillis() is positive, then getSoftMinEvictableIdleTimeMillis() is ignored).

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.soft-min-evictable-idle-time-millis=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          soft-min-evictable-idle-time-millis: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.soft-min-evictable-idle-time-millis="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_SOFT_MIN_EVICTABLE_IDLE_TIME_MILLIS="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.soft-min-evictable-idle-time-millis="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.test-on-borrow=false

Returns whether objects borrowed from the pool will be validated before being returned from the borrowObject() method. Validation is performed by the validateObject() method of the factory associated with the pool. If the object fails to validate, it will be removed from the pool and destroyed, and a new attempt will be made to borrow an object from the pool.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.test-on-borrow=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          test-on-borrow: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.test-on-borrow="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_TEST_ON_BORROW="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.test-on-borrow="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.test-on-create=false

Returns whether objects created for the pool will be validated before being returned from the borrowObject() method. Validation is performed by the validateObject() method of the factory associated with the pool. If the object fails to validate, then borrowObject() will fail.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.test-on-create=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          test-on-create: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.test-on-create="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_TEST_ON_CREATE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.test-on-create="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.test-on-return=false

Returns whether objects borrowed from the pool will be validated when they are returned to the pool via the returnObject() method. Validation is performed by the validateObject() method of the factory associated with the pool. Returning objects that fail validation are destroyed rather then being returned the pool.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.test-on-return=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          test-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.test-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_TEST_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.test-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.pool.test-while-idle=false

Returns whether objects sitting idle in the pool will be validated by the idle object evictor ( if any - see setTimeBetweenEvictionRunsMillis(long)). Validation is performed by the validateObject() method of the factory associated with the pool. If the object fails to validate, it will be removed from the pool and destroyed.

org.apereo.cas.configuration.model.support.redis.RedisPoolProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.pool.test-while-idle=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        pool: 
          test-while-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.pool.test-while-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_POOL_TEST_WHILE_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.pool.test-while-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.sentinel.node=

list of host:port pairs.

org.apereo.cas.configuration.model.support.redis.RedisSentinelProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.sentinel.node=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        sentinel: 
          node: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.sentinel.node="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_SENTINEL_NODE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.sentinel.node="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.connect-timeout=PT10S

Connection timeout.

This settings supports the java.time.Duration syntax ^[?].

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.connect-timeout=PT10S

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        connect-timeout: "PT10S"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.connect-timeout="PT10S" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CONNECT_TIMEOUT="PT10S"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.connect-timeout="PT10S"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.protocol-version=RESP3

Redis protocol version.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.protocol-version=RESP3

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        protocol-version: "RESP3"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.protocol-version="RESP3" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_PROTOCOL_VERSION="RESP3"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.protocol-version="RESP3"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.read-from=

Setting that describes how Lettuce routes read operations to replica nodes. Note that modes referencing MASTER/SLAVE are deprecated (but still supported) in the Lettuce redis client dependency so migrate config to UPSTREAM/REPLICA. Available values are as follows:

UPSTREAM: Read from the current upstream node.
UPSTREAMPREFERRED: Read from the upstream node, but if it is unavailable, read from replica nodes.
MASTER: Read from the current upstream node.
MASTERPREFERRED: Read from the upstream node, but if it is unavailable, read from replica nodes.
SLAVE: Read from replica nodes.
SLAVEPREFERRED: Read from the replica nodes, but if none is unavailable, read from the upstream node.
REPLICA: Read from replica nodes.
REPLICAPREFERRED: Read from the replica nodes, but if none is unavailable, read from the upstream node.
ANY: Read from any node of the cluster.
ANYREPLICA: Read from any replica node of the cluster.
NEAREST: Read from the nearest node.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.read-from=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        read-from: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.read-from="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_READ_FROM="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.read-from="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.scan-count=0

Redis scan count option. When and if specified, SCAN operations would be "counted" or limited by this serting. While SCAN does not provide guarantees about the number of elements returned at every iteration, it is possible to empirically adjust the behavior of SCAN using the COUNT option. Basically with COUNT the user specified the amount of work that should be done at every call in order to retrieve elements from the collection. This is just a hint for the implementation, however generally speaking this is what you could expect most of the times from the implementation.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.scan-count=0

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        scan-count: "0"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.scan-count="0" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_SCAN_COUNT="0"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.scan-count="0"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.share-native-connections=

The shared native connection is never closed by Lettuce connection, therefore it is not validated by default when connections are retrieved. If this setting is true, a shared connection will be used for regular operations and a connection provider will be used to select a connection for blocking and tx operations only, which should not share a connection. If native connection sharing is disabled, new (or pooled) connections will be used for all operations. By default, multiple connections share a single thread-safe native connection. If you enable connection pooling, then native connection sharing will be disabled and the connection pool will be used for all operations. You may however explicitly control connection sharing via this setting as an override.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.share-native-connections=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        share-native-connections: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.share-native-connections="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_SHARE_NATIVE_CONNECTIONS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.share-native-connections="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.timeout=PT60S

Command timeout.

This settings supports the java.time.Duration syntax ^[?].

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.timeout=PT60S

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        timeout: "PT60S"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.timeout="PT60S" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_TIMEOUT="PT60S"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.timeout="PT60S"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.uri=

Database URI.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.uri=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        uri: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.uri="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_URI="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.uri="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.use-ssl=false

Whether or not to use SSL for connection factory.

org.apereo.cas.configuration.model.support.redis.RedisTicketRegistryProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.use-ssl=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        use-ssl: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.use-ssl="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_USE_SSL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.use-ssl="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

# The signing/encryption algorithm to use.
# cas.ticket.registry.redis.crypto.alg=AES

# Whether crypto operations are enabled.
# cas.ticket.registry.redis.crypto.enabled=true

# Encryption key size.
# cas.ticket.registry.redis.crypto.encryption.key-size=16

# The signing key size.
# cas.ticket.registry.redis.crypto.signing.key-size=512

# Whether adaptive topology refreshing using all available refresh triggers should be used.
# cas.ticket.registry.redis.cluster.adaptive-topology-refresh=false

# Whether to discover and query all cluster nodes for obtaining the cluster topology.
# cas.ticket.registry.redis.cluster.dynamic-refresh-sources=true

# The max number of redirects to follow.
# cas.ticket.registry.redis.cluster.max-redirects=0

# List of nodes available in the redis cluster.
# cas.ticket.registry.redis.cluster.nodes=

# Identifier of this node.
# cas.ticket.registry.redis.cluster.nodes[0].id=

# Name of this node.
# cas.ticket.registry.redis.cluster.nodes[0].name=

# Enables periodic refresh of cluster topology and sets the refresh period.
# cas.ticket.registry.redis.cluster.topology-refresh-period=

# Returns whether or not the pool serves threads waiting to borrow objects fairly.
# cas.ticket.registry.redis.pool.fairness=false

# Returns whether the pool has LIFO (last in, first out) behaviour with respect to idle objects - always returning the most recently used object from the pool, or as a FIFO (first in, first out) queue, where the pool always returns the oldest object in the idle object pool.
# cas.ticket.registry.redis.pool.lifo=true

# Max number of connections that can be allocated by the pool at a given time.
# cas.ticket.registry.redis.pool.max-active=8

# Max number of "idle" connections in the pool.
# cas.ticket.registry.redis.pool.max-idle=8

# Maximum amount of time (in milliseconds) a connection allocation should block before throwing an exception when the pool is exhausted.
# cas.ticket.registry.redis.pool.max-wait=-1

# Sets the minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any - see setTimeBetweenEvictionRunsMillis(long)).
# cas.ticket.registry.redis.pool.min-evictable-idle-time-millis=0

# Target for the minimum number of idle connections to maintain in the pool.
# cas.ticket.registry.redis.pool.min-idle=0

# Sets the maximum number of objects to examine during each run (if any) of the idle object evictor thread.
# cas.ticket.registry.redis.pool.num-tests-per-eviction-run=0

# Sets the minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any - see setTimeBetweenEvictionRunsMillis(long)), with the extra condition that at least minIdle object instances remain in the pool.
# cas.ticket.registry.redis.pool.soft-min-evictable-idle-time-millis=0

# Returns whether objects borrowed from the pool will be validated before being returned from the borrowObject() method.
# cas.ticket.registry.redis.pool.test-on-borrow=false

# Returns whether objects created for the pool will be validated before being returned from the borrowObject() method.
# cas.ticket.registry.redis.pool.test-on-create=false

# Returns whether objects borrowed from the pool will be validated when they are returned to the pool via the returnObject() method.
# cas.ticket.registry.redis.pool.test-on-return=false

# Returns whether objects sitting idle in the pool will be validated by the idle object evictor ( if any - see setTimeBetweenEvictionRunsMillis(long)).
# cas.ticket.registry.redis.pool.test-while-idle=false

# list of host:port pairs.
# cas.ticket.registry.redis.sentinel.node=

# Connection timeout.
# cas.ticket.registry.redis.connect-timeout=PT10S

# Redis protocol version.
# cas.ticket.registry.redis.protocol-version=RESP3

# Setting that describes how Lettuce routes read operations to replica nodes.
# cas.ticket.registry.redis.read-from=

# Redis scan count option.
# cas.ticket.registry.redis.scan-count=0

# The shared native connection is never closed by Lettuce connection, therefore it is not validated by default when connections are retrieved.
# cas.ticket.registry.redis.share-native-connections=

# Command timeout.
# cas.ticket.registry.redis.timeout=PT60S

# Database URI.
# cas.ticket.registry.redis.uri=

# Whether or not to use SSL for connection factory.
# cas.ticket.registry.redis.use-ssl=false

cas.ticket.registry.redis.crypto.encryption.key=

The encryption key. The encryption key by default and unless specified otherwise must be randomly-generated string whose length is defined by the encryption key size setting.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.encryption.key=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          encryption: 
            key: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.encryption.key="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENCRYPTION_KEY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.encryption.key="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.signing.key=

The signing key is a JWT whose length is defined by the signing key size setting.

org.apereo.cas.configuration.model.core.util.SigningJwtCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.signing.key=...

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          signing: 
            key: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.signing.key="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_SIGNING_KEY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.signing.key="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.alg=AES

The signing/encryption algorithm to use.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedSigningJwtCryptographyProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.alg=AES

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          alg: "AES"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.alg="AES" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ALG="AES"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.alg="AES"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.enabled=true

Whether crypto operations are enabled.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedSigningJwtCryptographyProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.enabled=true

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          enabled: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.enabled="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENABLED="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.enabled="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.encryption.key-size=16

Encryption key size.

org.apereo.cas.configuration.model.core.util.EncryptionRandomizedCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.encryption.key-size=16

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          encryption: 
            key-size: "16"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.encryption.key-size="16" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_ENCRYPTION_KEY_SIZE="16"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.encryption.key-size="16"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.ticket.registry.redis.crypto.signing.key-size=512

The signing key size.

org.apereo.cas.configuration.model.core.util.SigningJwtCryptoProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.ticket.registry.redis.crypto.signing.key-size=512

CAS properties can be specified using the YAML syntax:

cas: 
  ticket: 
    registry: 
      redis: 
        crypto: 
          signing: 
            key-size: "512"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.ticket.registry.redis.crypto.signing.key-size="512" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_TICKET_REGISTRY_REDIS_CRYPTO_SIGNING_KEY_SIZE="512"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.ticket.registry.redis.crypto.signing.key-size="512"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

This CAS feature is able to accept signing and encryption crypto keys. In most scenarios if keys are not provided, CAS will auto-generate them. The following instructions apply if you wish to manually and beforehand create the signing and encryption keys.

Note that if you are asked to create a JWK of a certain size for the key, you are to use the following set of commands to generate the token:

wget https://raw.githubusercontent.com/apereo/cas/master/etc/jwk-gen.jar
java -jar jwk-gen.jar -t oct -s [size]

The outcome would be similar to:

{
  "kty": "oct",
  "kid": "...",
  "k": "..."
}

The generated value for k needs to be assigned to the relevant CAS settings. Note that keys generated via the above algorithm are processed by CAS using the Advanced Encryption Standard (AES) algorithm which is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology.

Configuration Metadata

The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.

Be Selective

This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.

YAGNI

Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.

Naming Convention

Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc.

Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.

Validation

Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.

Indexed Settings

CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.

Eviction Policy

Redis manages the internal eviction policy of cached objects via its time-alive settings. The timeout is the ticket’s timeToLive value. So you need to ensure the cache is alive long enough to support the individual expiration policy of tickets, and let CAS clean the tickets as part of its own cleaner if necessary.

Ticket Registry Locking

This ticket registry implementation automatically supports distributed locking. The schemas and structures that track locking operations should be automatically created by CAS using Spring Integration Redis support.