Hi Steve,
With regards to cache hits, when we are dealing with collections the hit rate
is very high. For example if a policy (or set of policies) applies to a
collection, then the objects within that collection inherit the policies. When
a user browses objects within a collection, each object returned is evaluated
and unless they specifically contain their own poicies, they are evaluated
against the policies in the parent. So if you were browsing through a hundred
objects within a collection, the user is evaluated against the collection only
once for the first object hit and then cached... and the reamining 99 would hit
the cache...
Similarly, if you do a search for objects, the ones that are part of common
collections would only need to be evaluated once... The performance saving is
considerable, because xacml evaluation is quite expensive. That is also why we
index policies so that we can grab only the policies relevant to the request
for evaluation.
With regards to the restrictions on policies, this can help... however, I've
always been against placing restrictions on policies as I have felt that the
flexibility and ability to handle arbitrary complexity of XACML was what made
it so good... As soon as we start designing within limitations we start to
encroach on that flexibility and move away from what XACML is all about.
Thanks,
Nish
________________________________
From: Steve Bayliss [[email protected]]
Sent: Saturday, 20 February 2010 12:03 AM
To: 'FC Developers List'
Subject: [Fedora-commons-developers] FeSL policy evaluation performance and
caching
Some thoughts I've had about access control performance in FeSL which I'd
welcome feedback on.
It is likely that XACML policy evaluation performance could be improved by
moving to a different XACML engine. However it may still be the case that
policy evaluation proves to be a computationally expensive process, with a
resulting impact on overall performance.
Current FeSL policy evaluation caching
======================================
The current FeSL implementation does include a caching mechanism - so that
when a XACML request context is received for evaluation, the cache is
searched for the same request, and if an entry is present the cached
response is provided. A cache "hit" will only occur if exactly the same
request is received.
XACML policies, resource and subject identification
===================================================
Currently XACML policies can be specified at a very granular level - for
instance down to individual resources (digital objects, datastreams) and
individual users. The impact of this is that XACML request contexts need to
include individual user IDs and resource IDs. With the current caching
mechanism there will only be a hit when an individual user requests the same
action on the same resource - so with for instance 10,000 potential users
and 10,000 resources this means a very large number of potential request
contexts, and probably very few cache hits.
If restrictions were placed on the kinds of XACML policies that can be
specified to limit resource identification to collection membership, and
user identification to user group (or other LDAP attributes for instance)
membership, this could reduce significantly the potential number of cache
entries - and increase the likelihood of hits on the cache. For instance if
there were 100 user groups and 100 collections, this reduces the number of
potential xacml request contexts to 10,000; and it means there would be a
hit on the cache when two different users belonging to the same group access
two different resources belonging to the same collection.
The question here is whether the access control use-cases that are out there
require the current level of granularity. (And if there are just a few
special cases where a policy does need to be specified at an individual user
x resource level, user groups and collections specific to the user and
resource could be created to implement this).
XACML request contexts passed for evaluation.
=============================================
There would need to be some specification of what resource identification
attributes and subject (user) identification attributes are allowable in
policies (either repository-wide, or potentially through content models).
It would mean modifying how XACML request contexts are built to only include
the specified resource and subject identification attributes.
Longer-term, there is a desire to be able to specify policies against
resources based on relationships, the content model of an object, etc. So
the approach would need to take this into account to allow additional
resource (and subject) identification attributes to be specified in the
future.
Regards
Steve
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
