jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Rethinking access control evaluation
Date Mon, 07 Oct 2013 07:41:20 GMT
hi jukka

we never have aces that effect just one single node. the effect
is *always* inherited to the complete subtree unless there are
additional restrictions that narrow the effect to those nodes
and properties in the subtree that match a given pattern.

this is how a backwards compatible implementation must behave
and i don't remember how many time i already explained this.

similarly it's one of core requirements of oak that we no longer
have a limitation with the number of access content entries
defined in the content tree. there are in fact a lot of customers
that are suffering from that limitation nowadays and it's our
own product that is limited by the current shortcoming of jackrabbit.
we definitely do have need for huge amount of ac content without
having any performance draw back... it might well be that you are
not aware of these use cases but feel asserted that they exist
and that i am not going to invent use cases that make the whole
story complicated if i can have it simple.

one additional thing we must be aware of:
SlingRepository#loginAdministrative
as finally been deprecated as it's always associated with critical
security issues. the replacement will be a setup with service
users that have dedicated permissions. in other words: we will
have a lot more access control content for all the service users
and we will have long-living service user sessions that register
observation listeners. this is a different situation than we have
nowadays were all long-living sessions are associated with the
admin session.

apart from existing requirements and constraints we already have
(there are quite a lot), i am also collecting use-cases for all
kind of access control setup scenarios where a different access
control model might be desirable underneath a given subtree of
the repository. in other words: the new OAK setup must allow
for custom extensions and it's very likely that we will have to
add even more complexity in terms of effective policies present
at a given subtree.

tobi and myself had a lot of discussions during the oakathon last
week regarding access control and security requirements in general.
no final decisions yet... but a lot of ideas that we kept collecting
over last couple of years.

kind regards
angela


On 10/5/13 5:31 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Fri, Oct 4, 2013 at 8:29 PM, Tobias Bocanegra <tripod@apache.org>
>wrote:
>> that's exactly the new algorithm Angela is working on right now
>
>Great!
>
>> However, it's not so simple since we also need to consider higher
>> level ACEs with restrictions. I.e. even if you know there are no more
>> ACLs beyond a specific node, there could still be a an earlier ACE
>> with a restriction that matches an item path further down.
>
>A few years ago in Apache Tika I solved a structurally similar problem
>with a state machine. The idea, applied to Oak, would be to model the
>effect of ACEs as state machines that switch from one state to another
>as we descend down the tree. Something like this:
>
>    interface EffectivePermission {
>
>        /**
>         * Returns the effect of this permission on the specified child
>node,
>         * or {@code null} if this permission does not apply to that
>subtree.
>         */
>        EffectivePermission getPermissionForChildNode(
>            String name, NodeState state);
>
>    }
>
>The effect of a normal ACE that applies to the entire subtree would
>remain unchanged for all descendants:
>
>    public EffectivePermission getPermissionForChildNode(
>            String name, NodeState state) {
>        return this;
>    }
>
>An ACE that's limited to just the node on which it was defined, would
>have no effect on descendants:
>
>    public EffectivePermission getPermissionForChildNode(
>            String name, NodeState state) {
>        return null;
>    }
>
>More complex restrictions (glob patterns, type matches, etc.) can be
>implemented with this same pattern. As an example, the mentioned
>solution in Tika implements a fairly complete XPath subset using this
>approach: 
>https://github.com/apache/tika/tree/trunk/tika-core/src/main/java/org/apac
>he/tika/sax/xpath.
>
>> Also keep in mind, that the performance of the algorithm really
>> depends on the ACL distribution. for example, repositories with very
>> restrictive ACLs on every "document" would benefit from the bottom-up
>> approach. So I think that we need both and find a way to choose the
>> strategy automatically or by configuration.
>
>Do we have real-world examples of such ACL-heavy repositories? Do they
>also require optimum performance? I'm not aware of any such use cases,
>but that of course doesn't mean they don't exist.
>
>If possible I'd rather avoid the extra complexity and go with just a
>single strategy that's optimized for the kinds of repositories we
>normally see.
>
>BR,
>
>Jukka Zitting


Mime
View raw message