Attribute caching

Policy evaluation often requires retrieving attribute values from external sources using Attribute Connectors. By using a caching mechanism for the attribute values fetched from Attribute Connectors, you can reduce overhead and optimize the performance of the Access Decision Service (ADS). Caching can make authorization requests faster by avoiding the need to repeatedly request the help of Attribute Connectors for attribute values that have not changed.

The domain specifies whether caching is required for an attribute and what the desired cache parameters for this attribute are. For more information on how to use attribute caching refer to the Attribute cache section of the YAML-format domain file analysis.

When a cache configuration is defined in the domain.yaml file then ADS will cache attributes' data locally.

note

To ensure successful attribute caching with Attribute Connectors (including custom connectors using the custom attribute connectors API), every attribute to be cached must be formally declared in both the domain dictionary and the cache configuration section.

Distributed caching

ADS supports distributed caching where attribute values from Attribute Connectors can be cached and replicated across multiple ADS instances.

You can enable distributed caching in one of the following ways:

• Enable the feature manually in your deployment.yaml configuration file as described in Enable distributed caching.
• Enable the feature during a Kubernetes deployment using Helm as described in the Final steps of the Kubernetes deployment section.

When distributed caching is enabled, a distributed cache cluster is formed in a shared network among multiple ADS instances, also called nodes.

Cluster formation

The cluster formation process consists of discovering available nodes within the environment that form the cluster, and then establishing a robust communication between them.

Cluster discovery methods

ADS supports the following two different discovery methods for identifying cluster members within your network:

• IP Multicast
• DNS Query

info

Cluster name is the key factor for cluster formation. Regardless of the discovery method, a cluster will only be formed among nodes with the same cluster name.

IP Multicast

IP Multicast is a communication method for simultaneously transmitting data to multiple recipients and relies on User Datagram Protocol (UDP) to send messages to all nodes within a network.

By default, the distributed cache feature uses multicast to identify cluster members and send multicast messages to all nodes within the network. However, it's important to be aware of possible network overhead and flooding, especially when working with a large number of nodes in the network.

note

While multicast can function within a Kubernetes environment, its efficiency may be less than optimal due to network configurations and limitations imposed by Kubernetes.

DNS Query

Distributed cache can also use DNS (Domain Name System) as the method of network discovery and identification of nodes and cluster members within a network. This method involves querying DNS Address or DNS Service records (SRV records) with an external DNS service in order to discover cluster members.

note

In Kubernetes environments, DNS records are automatically generated for services. More specifically, in ADS deployments using Kubernetes, the Helm chart provided by Axiomatics generates a headless service, which provides information about all active Axiomatics service members in the cluster.

By using DNS-based discovery, you can simplify the management and accessibility of nodes and cluster members of your network. DNS also allows for dynamic updates, enabling nodes to register themselves with the DNS server when they join the network or cluster. This automatic registration and resolution of node names streamline the process of adding or removing nodes in dynamic network environments.

Cluster communication

Once the cluster is established, nodes use TCP (Transmission Control Protocol) for intra-cluster communication. You can also increase the security of the communication within the cluster by using encryption, as described in the Encrypt cluster communication section.

note

Depending on the number of nodes in the cluster, the process of cluster discovery and replication may cause overhead and increase the network load to your system.

Entry expiry and consistency

When an entry in the distributed cache expires on a node, a mechanism is in place to maintain a consistent state across all nodes. Specifically, the expiring node sends a remove command to other nodes, ensuring that the cache remains in a synchronized and coherent state. This approach helps avoid stale data and ensures that all nodes have consistent information.

Advantages

Distributed caching is suitable for environments where multiple instances of ADS operate with same domain configuration. This approach ensures that an attribute value fetched by one instance can be shared across all ADS instances.

More specifically, distribution of caching offers:

• Improved performance through attribute value replication.
• Uniform and consistent response times across all nodes.
• Reduced workload on downstream attribute sources like databases and LDAP.
• Cost savings by optimizing resource usage.
• Seamless scaling with cache warming for new nodes.
• Cache preservation during software upgrades.