Service caching and timeouts for Authorize gateway instances
Configure service caching and timeouts to enable faster data access and limit wait times for service responses.
Service caching
Caching improves decision evaluation performance and reduces latency by storing data retrieved from services for faster retrieval on subsequent service requests.
You can cache:
-
External service responses
You can’t use an LDAP Gateway service type to access user information stored in an on-premise LDAP directory. Learn more in Policies published to Authorize gateways.
-
PingOne policy data:
-
Resolved values from the built-in
PingOne.User
attribute -
Results of Is Member Of and Is Not Member Of condition comparisons
-
How caching works
The gateway instance uses a two-level cache to improve performance and minimize redundancy. A local in-memory cache acts as the level-one cache and the Redis instance acts as the level-two cache.
When making a call to a service, the gateway instance tries to load the level-one cache entry. If the entry isn’t found, the gateway instance calls the level-two cache. If no entry is found on either level, the gateway instance calls the service itself.
Cached values are local to each gateway instance. However, multiple gateways can share the same level-two Redis cache by pointing to the same Redis instance. You can’t clear the in-memory cache manually.
The gateway instance logs Redis cache connection status and health.
Configuring service caching
Pass the caching
JSON object to your gateway instance using one of the available configuration methods.
You can configure the level-two Redis cache in one of the following modes:
-
Single instance: Connect to a standalone Redis server
-
Cluster: Connect to a Redis cluster, including managed services like AWS ElastiCache
Redis Sentinel isn’t supported. |
Example caching
object for single instance mode:
{
"caching": {
"external": {
"redis": {
"uri": "redis://localhost:6379/0",
"mode": "SINGLE_INSTANCE",
"auth": {
"username": "admin",
"password": "password"
}
}
}
}
}
Example caching
object for cluster mode with AWS Elasticache:
{
"caching": {
"external": {
"redis": {
"uri": "redis://<elasticache-cluster-address>.cache.amazonaws.com:6379",
"mode": "CLUSTER"
}
}
}
}
Configuration properties for the caching
object:
Property | Required | Description |
---|---|---|
|
Required |
Specifies connection details. In For AWS ElastiCache, use |
|
Required |
Specifies the Redis mode. Accepted values are |
|
Required only for |
Specifies |
Configuring PingOne cache TTLs
To specify the time-to-live (TTL) for cached PingOne values, you must pass the pingone.cache.ttl-seconds
object to your gateway instance using one of the available configuration methods.
You can specify the TTL for cached external service values when defining those services in PingOne. Learn more in Connecting a service. |
You can specify any of the ttl-seconds
properties independently. For example, you can define only the user-resolver
TTL or only the global
TTL without including the other properties.
The following example pingone.cache.ttl-seconds
JSON object sets a global
cache TTL of 5 seconds, but specifies overrides for the user-resolver
and member-of-comparator
services:
{
"services": {
"pingone": {
"cache": {
"ttl-seconds": {
"global": 5,
"user-resolver": 2,
"member-of-comparator": 3
}
}
}
}
}
Configuration properties for the ttl-seconds
object:
Property | Required | Description |
---|---|---|
|
Optional |
Specifies the default TTL in seconds for all cached PingOne values. |
|
Optional |
Specifies the TTL in seconds for cached |
|
Optional |
Specifies the TTL in seconds for cached PingOne group membership comparisons. Overrides the |
PingOne timeouts
Timeouts control how long a gateway instance waits for a response from PingOne during policy evaluation. If a PingOne request exceeds its timeout, the request fails and policy evaluation continues based on the available data.
You can specify timeouts for PingOne requests when policies use:
-
Attributes resolved from the built-in
PingOne.User
attribute -
Is Member Of and Is Not Member Of condition comparators
All PingOne requests use a 1-second timeout by default. You can override this by setting a global service timeout or defining service-specific timeouts.
You can specify timeouts for external service requests when defining those services in PingOne. Learn more in Connecting a service. |
Configuring PingOne timeouts
Pass the pingone.timeout-seconds
object to your gateway instance using one of the available configuration methods.
You can specify any of the timeout-seconds
configuration properties independently. For example, you can define only the user-resolver
timeout or only the global
timeout without including the other properties.
You can specify timeouts without upper limits. Ensure that you adjust timeouts to meet your environment and service responsiveness requirements.
The following example pingone.timeout-seconds
JSON object sets a global
timeout of 1 second, but specifies overrides for the user-resolver
and member-of-comparator
services:
{
"services": {
"pingone": {
"timeout-seconds": {
"global": 1,
"user-resolver": 2,
"member-of-comparator": 3
}
}
}
}
Configuration properties for the timeout-seconds
object:
Property | Required | Description |
---|---|---|
|
Optional |
Specifies the timeout in seconds for all PingOne requests. |
|
Optional |
Specifies the timeout in seconds for |
|
Optional |
Specifies the timeout in seconds for PingOne group membership requests. Overrides the |