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 12:05:38 GMT
hi michael

i don't want to create yet another implementation that doesn't fit
our requirements... we had too many escalations due to the limitation
of jackrabbit core without being able to address them.

you have been involved in the recent discussion with our soco team
and they are definitely looking for scalable repository without
limitation in terms of access control content.

in other words: i want to ship oak with a ac setup that not only
covers the default setup. already with jackrabbit-core it was possible
to configure custom implementations of the permission evaluation and i
just know of one single case where this was actually considered an option.
that's why i came to the conclusion that we have to make sure that
we get rid of these limitations out of the box.

at the same time the permission eval should still be pluggable such that we
can extend or even replace the current model. but i consider this
an option for completely replacing the evaluation model (e.g.
each document comes with it's own permissions and there is no
inheritance at all)... i don't want to offer pluggability as
as workaround for limitations of the implementation. that's what
we had in the past: the limitations were known and communicated even
before releasing  jackrabbit 2.x and i was always told that
it's not a problem. this was simply not true... i learned my lession :-)

kind regards

On 10/7/13 9:59 AM, "Michael Marth" <mmarth@adobe.com> wrote:

>Hi Jukka,
>you are right that the majority of repositories we see (or at least that
>I see) have few principals and few ACLs. But as Angela mentioned there is
>a not-so-small number of cases with a very large number of principals
>(>100000, e.g. a public portal or forum) and/or a large number of ACLs
>(>50000, e.g. Intranet where ACLs are not hierarchic).
>From my POV it makes sense (as it was suggested on this thread) to
>optimize for the normal case (few ACLs) out of the box, but make the ACL
>evaluation pluggable, so that different strategies could be used in the
>different scenarios.
>On Oct 5, 2013, at 5:31 AM, Jukka Zitting wrote:
>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.

View raw message