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
