Caching Options

The Authorization Platform offers the following caching options:

• Identity Source Cache
• Scope Cache
• JWKS Cache
• PIP Cache

Identity Source Cache

The Identity Source cache can improve performance by caching Identity data fetched from Identity Data Sources. By using this cache option, the PlainID PDP can avoid calling the Identity Data Source for every Decision Request. It is considered best practice to use this cache when the Identity Data used in Policies is not very dynamic. For example, if your Identity Template source includes user attributes such as Job Title, Department, Location, etc., it might be logical to have this data cached since this type of data is unlikely to change often.

Key facts about the Identity Source cache:

• The cache duration is managed per Identity Source.
• The cache duration is defined (in seconds) under Identity Workspace Settings > Attribute sources > Cache Duration.
• If not defined, the default value for caching duration is 0 seconds. This means there is no cache and no decisions is saved.
• If changed in the PAP, the change is pushed to the PAA\Cloud PDP and is implemented when the previous TTL arrives or on restart of the PlainID PDP.

Scope Cache

The Scope cache option can improve performance by caching access decisions which are not likely to be changed very frequently. The PlainID PDP calculates the dynamic access decision and store it in the Redis cache store. When a new access decision request is sent during the cache period, the PlainID PDP checks if the cache contains a response for the same request. If there is a cached response for this same request, the PlainID PDP returns the cached response immediately instead of recalculating the decision again.

Key facts about the Scope cache:

• Managing cache for Access Decision responses calculated by the PlainID PDP uses the full PlainID PDP request as a cache key.
• The Cache Duration is managed per Scope.
• The cache duration is defined (in minutes) under Environment settings > Scopes  > Cache Duration.
• Users have the ability to establish IP and time conditions. These conditions, while in place, do not alter the calculation of cache keys, and they also do not impact the Scope cache.
• If changed in the PAP the change is be pushed to the PAA or cloud PDP and is then be implemented when the previous TTL arrives or on restart of the PlainID PDP.

JWKS (for incoming JWT validation)

The PlainID PDP is able to receive access decision requests with a JWT, both for authenticating the calling client and for sending Identity Data as part of the request. The incoming JWTs are validated for authenticity and expiration using prefetched keys from the configured JWKS URLs. These prefetched keys are cached in the PlainID PDP memory to be used for validation rather than calling the JWKS URL for each incoming request. The certificates information is refreshed from the JWKS URLs every hour by default (3,600,000 ms).

To change the JWKs Refresh Token:

1. Open the values-custom.yaml.
2. Add the following code:

runtime:
  extraEnv: {
    # Refresh JWKS time in miliseconds. For hybrid user to change in production
    REFRESH_JWKS : "3600000"
  }

3. Modify the REFRESH_JWKs.
4. Restart the service.

Secret Management (for signed PlainID PDP JWT Response)

The PlainID PDP can serve its responses as a signed JWT to the calling clients. The JWT signing process uses a public/private key pair. The Public Certificate is configured on the Scope UI and the Private Keys are fetched from the Secret Manager Service. To avoid repetitive calls to the Secret Manager, the PlainID PDP caches the Private Keys in its memory.

The PlainID PDP continuously monitors Scope data changes (every 1 minute) and upon Certificate changes, a refresh to the Private Keys from the Secret Manager is triggered.

Policy Information Point (PIP)

The PIP service provides caching options to improve performance by avoiding the need to reach out to external Data Sources for each and every query. Using the PIP caching options retrieves the external data source, or subsets of it, and hold it closer to the PIP service.

The caching mechanisms of the PIP service are defined and used on the PIP Views level, which means they cache the views data, which potentially already combines different data sources with the relevant Data Attributes for your Policy needs.

There are two caching mechanisms in the PIP service, Persistent Cache, In-Memory Cache:

1. Persistent Cache - this cache mechanism fetches the View data from external Data Sources and stores it in a persistent database, so it is retrieved directly from this DB in a more performant way.
2. In-Memory Cache - using this cache mechanism fetches the view data from external data sources and store it in the PIP service memory. This option allows fast querying the view directly in memory, but it requires loading significant data amounts into the memory.

Some considerations you need to take into account before using the PIP caching options:

• Size of data
• Complexity of views
• External data sources behind the views
• Frequency of source data updates

For more details and configuration, instructions see the Managing Views