What is distributed attribute caching?

Pablo Giambiagi   ·   Monday, September 18th, 2023

Distributed caching is an extension of the traditional single local cache as it is shared by policy decision points (PDPs).

This allows the system to pull together information from the attribute source that can be used at a later time when the data is needed again to make a decision.

Why is distributed caching important?

In the conventional attribute-based access control (ABAC) architecture, the policy decision point (PDP) employs attribute data to determine access permissions.

These attributes encompass various aspects, characteristics, or properties of the user, the resource in question, the context of access, and so forth.

Ideally, attribute data should remain as up-to-date as possible to ensure access control decisions rely on the most current information available.

However, transferring all attribute data into the PDP is often impractical due to data volume or its dynamic nature.

Conversely, retaining all attribute data within the system-of-record leads to prolonged decision making at the PDP as it must continually request attributes for every decision it makes.

To strike a balance, attribute caching offers a viable alternative.

By locally caching a portion of the attribute data, each PDP can expedite subsequent decisions involving the same attributes without the need to repeatedly access the original data sources.

In modern orchestrated deployment scenarios, the PDP is typically replicated and placed behind a load balancer.

Furthermore, the orchestrator can horizontally scale the system to meet demand and optimize infrastructure costs.

Predictably, this dynamic environment poses challenges to the advantages of locally caching attribute data at the PDP.

When new PDP instances are spun up, they encounter empty caches, and a PDP instance may find itself needing to retrieve an attribute that was just accessed by another PPD instance.

We are enhancing our distributed caching

Axiomatics has always had caching as a part of our authorization solution, but we are enhancing our caching capabilities so they match the challenges posed by modern elastic deployments.

This will introduce communication between caches.

The goal is that the communication will keep the same data in all caches (replication), regardless of which PDP instance retrieved it from the attribute source.

Before: Caching within Axiomatics Orchestrated Authorization solution

Our cloud-native PDP has offered local caching since day one as a part of our authorization solution.

So how does caching work?

When we start a query to find out information, the PDPs, if not using local caching, will go to an attribute source to find the data.

If caching isn’t in place, the next time there is a query the solution will ask for the same attributes from the attribute source as it requested before. This is the advantage of caching which shows up later.

With caching, the solution can remember some attributes if it is acceptable from an authorization perspective to use that old attribute as it is more efficient.

It is important to note that this is not done with every attribute, like time of day or exchange rates, which can change frequently.

It is only done with more static attributes such as roles, which don’t change as often.

Additionally, there are also policies around how long that attribute can be cached before checking again to see if something changed.

Let’s look at an analogy to illustrate this point –  let’s say there is a bank of three badge-activated elevators in a thirty story highrise building for a company. Each elevator goes to a different range of floors:

• Elevator 1 covers floors 1 – 10
• Elevator 2 covers floors 11 – 20
• Elevator 3 covers floors 21 – 30

Each elevator remembers which floor each person pushed to go to for the floors that they can access.

However, if John (who normally uses elevator 1) has to visit the 12th floor for a meeting, when he enters elevator 2 and scans his badge, it takes the elevator time to make a decision on whether to authorize him going to floor 12. It isn’t familiar with him so it has to go verify all of his details.

After: Caching within the Axiomatics Orchestrated Authorization solution

The goal of adding distributed caching to our solution is that if you have an enterprise with multiple PDPs as a part of the authorization deployment that the cache is shared among the PDPs.

The moment an enterprise adds more PDPs, if they only have local caching they have to start over each time.

This means you can’t predict how long it will take to answer a query as each point will have to reach out to the same database and ask for the same data again.

When doing this there is a risk of overloading the attribute source. As if every engine opens a connection it can cause the attribute source to overload.

When using distributed caching, the data is shared across every PDP so they don’t have to request the data from the attribute source each time there is a query.

This eliminates the risk of the attribute source overloading and reduces the amount of time it takes to complete the query.

Going back to our analogy, this is how it would work with distributed caching being introduced.

Each elevator would share their cached information with the other elevators.

Same scenario with John going to a meeting on floor 12, Elevator 1 has shared its cached information with Elevator 2 and 3.

So, when John scans his badge, it already knows he is an employee of the company and is authorized to travel to the 12th floor without the elevator having to go and check for itself, thus saving time.

Imagine that elevators represent PDPs.

So you can see how on a grander scale, distributed caching would help the organization manage authorization decisions in a more efficient manner.

See distributed caching in action

Request a demo with one of our solution experts to see distributed caching in action and learn more about our Orchestrated Authorization solution.