One way of improving the performance of a XACML engine is by using caching techniques. But caching implementation must be designed carefully.
Actually when remind the XACMLnetiq identity manager reference architecture, we could identify that, caching can be done in four places
1. XACML Policies can be cached. As policies usually be stored in a database or file system. for each request, if is not desirable to load them from database or file system. Therefore it is required to cache the XACML policies .
2. Attribute values that are retrieve from external pips can be cached. As those attribute values may be retrieved from then external source such as web services, remote jdbc and remote ldap servers, caching of those would be great.
3. XACML decisions can be cached in PDP level. Most of the use cases, same authorization query can hit the PDP multiple time, therefore it creates a considerable performance hit, If decision can be cached before hitting PDP.
4. XACML decisions can also be cached in PEP level. This would probably gain a magnificent performance hit, It means that PEP do not want to query the XACML PDP for authorization queries and this would save the time that spend the XACML query and response in the transport between PEP and PDP. But implementation of this would be tricky.
Let go through above mentioned, four type of caches in some details and identify the some important design consideration. Also let briefly discuss, how WSO2 Identity Server has implemented those.
Policy Cache
1. Policy cache must be updated when any updated is happened within the policy store.
2. Policy cache must be distributed among PDP nodes, If they have been clustered.
3. Whether to load all policies in to the cache or on demand loading policies. If all policies (1000 – 10000 policies) are loaded in to memory, where the limited resources are available, there can be OOM and performance issues.
WSO2 Identity Server stores XACML policy in the registry (basically in database). In clustered PDP setup, This registry would be shared across all nodes. If any policy updates are happened from the PAP, All policies must be reloaded in to the cache. (You can even load policies on demand. you may configure the maximum no of policies that can be kept in the cache. WSO2 Identity Server is used the Hazelcast for under line local caching implementation. The cache invalidation messages are distributing among cluster nodes by using the Hazelcast distributed caching implementation.
Attribute Cache
1. Attribute cache or cache entry must be updated (invalidated), when external attribute sources are updated.
2. Cache or cache entry updating (invalidating) messages must be distributed among clustered PDPs
Attribute cache would cache attribute values that are retrieved from all the PIP extensions. It is actually a common cache for all PIP extensions. But If PIP prefers to keep their own cache implementation, it is allowed by overriding the default cache. If you just go throw the API of the “PIPAttributeFinder”, you can see those methods.
WSO2 Identity Server provides set of APIs to invalidate the attribute cache or cache entries when ever external attribute source are updated. Attribute Cache also has been distributed among cluster nodes using Hazelcast caching implementation.
Decision Cache
1. PDP Decision cache must be invalidated, when policy cache updated, attribute cache is invalidated and global policy combining algorithm is updated.
2. Cache invalidating messages must be distributed among clustered PDPs
WSO2 Identity Server provides Hazelcast based local caching implementation as the decision cache. Cache is not distributed among cluster nodes. Only the cache invalidation messages are distributing by using the Hazelcast distributed caching implementation. Therefore if cache is invalidated in one node, All decision caches in other nodes are also invalidated.
PEP Decision Cache
1. PEP Decision cache must be invalidated when policy cache updated, attribute cache is invalidated, PDP decision cache is invalidated and global policy combining algorithm is updated.
2. Cache invalidation messages are must propagated PEP via a reliable way.
WSO2 Identity Server only provide the PDP, PAP and PIP functionality. PEP must be binded in to your application. But there is an implementation called PDP proxy, which would give an easy set of API for the application to deal with. This PDP Proxy source is not still implemented 100% and not publicly available and WSO2 would ship it with the entitlement mediator (which is available in WSO2ESB) in future.