1 Reply Latest reply on Nov 18, 2011 12:27 PM by dgradl

    XACML Caching

    anil.saldhana

      We have an article http://community.jboss.org/wiki/XACMLCachingForPerformance

       

      Dan has some good comments on caching in xacml engine. This thread will try to brainstorm performance enhancing xacml caching.

       

      A caveat to remember is that the PDP should make the correct decision. In the name of performance and use cases, if we add complexity, then the PDP results should be carefully evaluated to see that it does not permit when it should deny.

        • 1. Re: XACML Caching
          dgradl

          Performance is a key quality attribute that needs to be addressed in a non-trival implementation of XACML access control.   Caching is a potential feature to improve performance.  

           

          Ideally you just want the decision to execute quickly and efficiently.  At the risk of stating the obvious, there is a tradeoff with caching, you are trading execution time for memory usage.  In other words the decisioning is taking too much time, so you desire to speed that up by storing results in memory.    However, there are other ways to speed up the evaluation/address performance, which I will also write about soon in a separate thread. Caching in my opinon is actually one of the more complex ways to address it, but is also essential under certain conditions.

           

          In many usages, the execution of policies may be very quick and caching will not be necessary.  But there are cases that make it more important:

          • large number of policies/rules
          • complex policies/rules
          • remote PDP (not sure if anyone has tried to host the PDP as a remote service, there was a thread post requesting info on this but had no replies)

           

          There are several places where caching can be applied to address different needs

          • Policy caching - for the most part it does this already with file based policies (reads them into memory), but with a policy database you may wish to retrieve them everytime or cache all or a portion of them in the PDP
          • Target matching - searching through the policies to find the ones to execute can requiring traversing a complex tree, even if you cannot cache decision results, you may at least be able to find the applicable policies faster and execute the rules each time
          • Decision caching - caching the outcome of a decision, this is pretty complex if you want to ensure you don't give false results, and you want to make sure to maximize the number of hits, matching your cache entries on the full request context will not always result in an effective cache (see my comments in the link above).
          • Enforcement point caching - this is more or less the same as decision caching on the PEP side, but in the case of a remote PDP you will want to avoid remote invocations
          • Resource caching - if you use a resource directory along with ResourceFinders, you may wish to cache the directory of resources to avoid retrieving those repeatedly
          • PIP caching - the XACML library calls this an AttributeFinder, but in my opinion the finders play the role of a Policy Information Point in the XACML spec, and I prefer to call them as such.  However, you may wish to be able to cache the results of these finders as they may go off to various data stores

           

          There is an overriding principle that is essential, and you mentioned it Anil.  That is that you must be able to respond to a request with the CORRECT decision whether it came from cache or a fresh execution of the rules.

           

          There are general caching related requirements that apply to many types of caches:

          • Options for different caching eviction mechanisms (LRU, LFU, etc)
          • Configurable cache size
          • Ability to enable/disable
          • Distributed caching support

           

          There is at least one aspect that is critical:

          • Cache expiration and flushing - when policies or other key data change, it is important to flush the data from cache so that a new accurate result is computed - if I remove access to something to prevent a security issue it needs to take effect ASAP.

           

          I think that's plenty from me for the moment.