Dan Gradl [
http://community.jboss.org/people/dgradl] created the discussion
"Re: XACML Caching"
To view the discussion, visit:
http://community.jboss.org/message/637237#637237
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/637237#637237]
Start a new discussion in PicketBox Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]