CAS - Attribute Release Consent

Support is enabled by including the following module in the WAR Overlay:

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

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

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

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

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-consent-redis"
}

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.consent.redis.database=0

Database index used by the connection factory.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

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.consent.redis.database=0

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: 
  consent: 
    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.consent.redis.database="0" -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_CONSENT_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.consent.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.consent.redis.enabled=true

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

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.enabled=true

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.host=localhost

Redis server host.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.host=localhost

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.password=

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.password=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.redis.password="..." -jar build/libs/cas.war

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

export CAS_CONSENT_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.consent.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.consent.redis.port=6379

Redis server port.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.port=6379

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.

cas.consent.redis.username=

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.username=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      username: "..."

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.consent.redis.username="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_USERNAME="..."

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.consent.redis.username="..."

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.consent.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.

Note

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

cas.consent.redis.cluster.nodes[0].host=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.nodes[0].port=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

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

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.cluster.nodes[0].type=

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

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.

Note

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

cas.consent.redis.cluster.nodes[0].type=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.password=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.cluster.username=

The cluster connection's username.

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.

Note

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

cas.consent.redis.cluster.username=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      cluster: 
        username: "..."

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.consent.redis.cluster.username="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_CLUSTER_USERNAME="..."

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.consent.redis.cluster.username="..."

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.consent.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.

Note

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

cas.consent.redis.pool.enabled=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.sentinel.master=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.

# Database index used by the connection factory.
# cas.consent.redis.database=0

# Whether the module is enabled or not, defaults to true.
# cas.consent.redis.enabled=true

# Redis server host.
# cas.consent.redis.host=localhost

# Login password of the redis server.
# cas.consent.redis.password=

# Redis server port.
# cas.consent.redis.port=6379

# Login username of the redis server.
# cas.consent.redis.username=

# Server's host address.
# cas.consent.redis.cluster.nodes[0].host=

# Server's port number.
# cas.consent.redis.cluster.nodes[0].port=

# Set the id of the master node.
# cas.consent.redis.cluster.nodes[0].replica-of=

# Indicate the type/role of this node.
# cas.consent.redis.cluster.nodes[0].type=

# The cluster connection's password.
# cas.consent.redis.cluster.password=

# The cluster connection's username.
# cas.consent.redis.cluster.username=

# Enable the pooling configuration.
# cas.consent.redis.pool.enabled=false

# Name of Redis server.
# cas.consent.redis.sentinel.master=

_{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. In other words, you should only include this field in your
configuration if you need to modify the default value or if you need to turn on the feature controlled by the setting.}

cas.consent.redis.connect-timeout=PT10S

Connection timeout.

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

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.connect-timeout=PT10S

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.key-certificate-chain-file=

May be used when making SSL connections. Sets the certificate file to use for client authentication. This is typically an X.509 certificate file (or chain file) in PEM format.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.key-certificate-chain-file=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      key-certificate-chain-file: "..."

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.consent.redis.key-certificate-chain-file="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_KEY_CERTIFICATE_CHAIN_FILE="..."

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.consent.redis.key-certificate-chain-file="..."

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.consent.redis.key-file=

May be used when making SSL connections. Sets the key file for client authentication. The key is reloaded on each connection attempt that allows to replace certificates during runtime. This is typically a PKCS#8 private key file in PEM format.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.key-file=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      key-file: "..."

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.consent.redis.key-file="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_KEY_FILE="..."

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.consent.redis.key-file="..."

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.consent.redis.key-password=

The password of the #keyFile, or null if it's not password-protected.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.key-password=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      key-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.consent.redis.key-password="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_KEY_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.consent.redis.key-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.consent.redis.protocol-version=RESP3

Redis protocol version.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.protocol-version=RESP3

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.read-from=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.scan-count=0

Redis scan count option. When and if specified, SCAN operations would be "counted" or limited by this setting. 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.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.scan-count=0

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.share-native-connections=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.start-tls=false

Start mutual TLS. In order to support TLS, Redis should be configured with a X.509 certificate and a private key. In addition, it is necessary to specify a CA certificate bundle file or path to be used as a trusted root when validating certificates.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.start-tls=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      start-tls: "..."

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.consent.redis.start-tls="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_START_TLS="..."

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.consent.redis.start-tls="..."

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.consent.redis.timeout=PT60S

Command timeout.

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

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.timeout=PT60S

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.uri=

Database URI.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.uri=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.redis.uri="..." -jar build/libs/cas.war

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

export CAS_CONSENT_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.consent.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.consent.redis.use-ssl=false

Whether or not to use SSL for connection factory.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.use-ssl=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.

cas.consent.redis.verify-peer=true

Control how peer verification is handled with redis connections. Peer verification is a security feature that checks if the host you're connecting to is who it says it is. This is often done by checking a digital certificate.

org.apereo.cas.configuration.model.support.consent.RedisConsentProperties.

_{How can I configure this property?}

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

Note

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

cas.consent.redis.verify-peer=true

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      verify-peer: "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.consent.redis.verify-peer="true" -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_VERIFY_PEER="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.consent.redis.verify-peer="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.consent.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.

Note

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

cas.consent.redis.cluster.adaptive-topology-refresh=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.dynamic-refresh-sources=true

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.max-redirects=0

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.nodes=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.nodes[0].id=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.nodes[0].name=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.cluster.topology-refresh-period=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.fairness=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.lifo=true

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.max-active=8

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.max-idle=8

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.pool.max-wait=PT5S

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.

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

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.

Note

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

cas.consent.redis.pool.max-wait=PT5S

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      pool: 
        max-wait: "PT5S"

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.consent.redis.pool.max-wait="PT5S" -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_POOL_MAX_WAIT="PT5S"

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.consent.redis.pool.max-wait="PT5S"

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.consent.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.

Note

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

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

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.min-idle=0

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

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

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

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

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.test-on-borrow=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.test-on-create=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.test-on-return=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.pool.test-while-idle=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.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.

Note

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

cas.consent.redis.sentinel.node=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    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.consent.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_CONSENT_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.consent.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.consent.redis.sentinel.password=

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.

Note

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

cas.consent.redis.sentinel.password=...

CAS properties can be specified using the YAML syntax:

cas: 
  consent: 
    redis: 
      sentinel: 
        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.consent.redis.sentinel.password="..." -jar build/libs/cas.war

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

export CAS_CONSENT_REDIS_SENTINEL_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.consent.redis.sentinel.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.

# Connection timeout.
# cas.consent.redis.connect-timeout=PT10S

# May be used when making SSL connections.
# cas.consent.redis.key-certificate-chain-file=

# May be used when making SSL connections.
# cas.consent.redis.key-file=

# The password of the {@link #keyFile}, or {@code null} if it's not password-protected.
# cas.consent.redis.key-password=

# Redis protocol version.
# cas.consent.redis.protocol-version=RESP3

# Setting that describes how Lettuce routes read operations to replica nodes.
# cas.consent.redis.read-from=

# Redis scan count option.
# cas.consent.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.consent.redis.share-native-connections=

# Start mutual TLS.
# cas.consent.redis.start-tls=false

# Command timeout.
# cas.consent.redis.timeout=PT60S

# Database URI.
# cas.consent.redis.uri=

# Whether or not to use SSL for connection factory.
# cas.consent.redis.use-ssl=false

# Control how peer verification is handled with redis connections.
# cas.consent.redis.verify-peer=true

# Whether adaptive topology refreshing using all available refresh triggers should be used.
# cas.consent.redis.cluster.adaptive-topology-refresh=false

# Whether to discover and query all cluster nodes for obtaining the cluster topology.
# cas.consent.redis.cluster.dynamic-refresh-sources=true

# The max number of redirects to follow.
# cas.consent.redis.cluster.max-redirects=0

# List of nodes available in the redis cluster.
# cas.consent.redis.cluster.nodes=

# Identifier of this node.
# cas.consent.redis.cluster.nodes[0].id=

# Name of this node.
# cas.consent.redis.cluster.nodes[0].name=

# Enables periodic refresh of cluster topology and sets the refresh period.
# cas.consent.redis.cluster.topology-refresh-period=

# Returns whether or not the pool serves threads waiting to borrow objects fairly.
# cas.consent.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.consent.redis.pool.lifo=true

# Max number of connections that can be allocated by the pool at a given time.
# cas.consent.redis.pool.max-active=8

# Max number of "idle" connections in the pool.
# cas.consent.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.consent.redis.pool.max-wait=PT5S

# 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.consent.redis.pool.min-evictable-idle-time-millis=0

# Target for the minimum number of idle connections to maintain in the pool.
# cas.consent.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.consent.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.consent.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.consent.redis.pool.test-on-borrow=false

# Returns whether objects created for the pool will be validated before being returned from the borrowObject() method.
# cas.consent.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.consent.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.consent.redis.pool.test-while-idle=false

# list of host:port pairs.
# cas.consent.redis.sentinel.node=

# Login password of the sentinel server.
# cas.consent.redis.sentinel.password=

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.

Note

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. 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.

Redis - Attribute Consent Storage

Configuration

Configuration Metadata

Be Selective

YAGNI

Naming Convention

Validation

Indexed Settings