Re: How does having lot of ACL (for different principals) on a single node affect performance

[Angela Schreiber]

hi vikas

the setup you describe below sounds pretty similar what alex and myself
discussed recent with consultants based on some customer requirements.

in particular the fact that you bake different permission relevant
attributes into the naming convention for a groups sounds pretty wrong
to me and doesn't seem like a good solution over time as the number
of content and roles evolve. and the permission set will get awfully
complicated with the default model given the fact that if you would
write it down in in words it would be most probably quite straight
forward.

if you wish we could take that offline and discuss it over all call
that needs less time writing up all the details... we might also see
at that point how much your setup is inline with what alexC and myself
recently discussed for that customer and how we agreed there to move
forward.

would that work for you?

kind regards
angela

On 09/11/16 11:17, "Vikas Saurabh"  wrote:

>Thanks Angela and Michael. Angela, I've replied to a few part inline
>below.
>
>>>The most trivial idea was to have a
>>>synthetic-group-per-persona-per-such-node and add/remove members to
>>>these groups. This approach has obvious side-effects:
>>>* systems gets flooded with system-generated-groups thus requiring
>>>special UI for user/group management
>>
>> Are you talking about real users/groups as defined by the Jackrabbit
>> user management or about simple principals as we discussed during the
>> last Oakathon? For the latter the UI is limited to crx-explorer which
>> is the only UI Adobe provides that exposes the principal management UI.
>>
>
>I meant groups via jackrabbit user management. I was leaning out of
>this option due to point#3 (eerie feeling)
>
>>>* can potentially affect login performance - I haven't checked how
>>>OAK-3003 works.. maybe, it's a non-issue
>>
>> Without knowing the exact details of your use-case: depending on how
>>your
>> synthetic-groups are envisioned to work and whether or not this member
>> is really intended to be edited and managed through the CQ user
>>management
>> UI, you may consider solving this with principal management rather than
>> user management... see above and also referring to the conversation
>> we had last time.
>>
>
>To elaborate a bit on use-case: consider 2 personas like ""
>and "". Where  (or ) is essentially a
>"synonym" of what type of privileges do s have (it might be
>more that read... it might be read on current node + some more privs
>for content-structure under it.
>All  need to have same type of access on the content.
>Similarly  have same perms. The group idea was to create
>"content-1-viewer" and "content-1-editor" group, give relevant access
>on "content-1" to these groups, and then make actual users member of
>these groups depending on if they are viewer or editor
>(there's another persona "author" who is stronger that editor in the
>sense that they are allowed to make others , , etc...
>I kept to 2 for simplification.
>
>>>The other end of the spectrum is to provide explicit ACLs on the node
>>>per principal. It's ok for us to go this way... but we ended up with
>>>an open question on the subject the mail. Do we know how ACL
>>>evaluation performance behave wrt number-of-ACLs on a node - assuming
>>>ACLs-per-principal won't be a big number?
>>
>> The access control content as stored with the individual nodes in ACLs
>> and ACEs is _not_ used for the evaluation at all. Permission evaluation
>> and thus performance of permission evaluation of the default
>>authorization
>> model is purely defined by the performance of compiling effective
>> permissions from the data stored in the permission store at
>> /jcr:system/rep:permissionStore.
>>
>> In other words: the permission evaluation is based on the following
>> pieces:
>>
>> 1. the set of principals as pushed to the subject upon authentication
>> 2. permission-entries stored separately for each principal in the
>> perm-store
>> 3. separation of the 2 types of principals as defined by java (Principal
>> and java.security.acl.Group)
>>
>> Based on the original design goals we laid out for Oak promising that
>> flat hierarchies of non-ordered nodes is supported, I would not expect
>> issues with a huge amount of permission entries in the store for a
>>single
>> principal.
>
>That's good to know :). So, unless we're talking about editing
>permissions on the node, it should be ok for having large number of
>ACL/Es.
>
>>
>> On the other hand: access control entries as edited by the default
>> user facing access control management implementation are collected in
>> a list which be definition has an order. this is reflected by the
>> content structure storing ACEs as nodes below a policy node that is
>>defined
>> to have orderable children. Since support for huge flat hierarchies
>> of _orderable_ nodes was a explicit non-goal of Oak, I would expect
>> to see limitations here when it comes to tens of thousands of ACEs
>> for a given 

Re: How does having lot of ACL (for different principals) on a single node affect performance

[Vikas Saurabh]

Thanks Angela and Michael. Angela, I've replied to a few part inline below.

>>The most trivial idea was to have a
>>synthetic-group-per-persona-per-such-node and add/remove members to
>>these groups. This approach has obvious side-effects:
>>* systems gets flooded with system-generated-groups thus requiring
>>special UI for user/group management
>
> Are you talking about real users/groups as defined by the Jackrabbit
> user management or about simple principals as we discussed during the
> last Oakathon? For the latter the UI is limited to crx-explorer which
> is the only UI Adobe provides that exposes the principal management UI.
>

I meant groups via jackrabbit user management. I was leaning out of
this option due to point#3 (eerie feeling)

>>* can potentially affect login performance - I haven't checked how
>>OAK-3003 works.. maybe, it's a non-issue
>
> Without knowing the exact details of your use-case: depending on how your
> synthetic-groups are envisioned to work and whether or not this member
> is really intended to be edited and managed through the CQ user management
> UI, you may consider solving this with principal management rather than
> user management... see above and also referring to the conversation
> we had last time.
>

To elaborate a bit on use-case: consider 2 personas like ""
and "". Where  (or ) is essentially a
"synonym" of what type of privileges do s have (it might be
more that read... it might be read on current node + some more privs
for content-structure under it.
All  need to have same type of access on the content.
Similarly  have same perms. The group idea was to create
"content-1-viewer" and "content-1-editor" group, give relevant access
on "content-1" to these groups, and then make actual users member of
these groups depending on if they are viewer or editor
(there's another persona "author" who is stronger that editor in the
sense that they are allowed to make others , , etc...
I kept to 2 for simplification.

>>The other end of the spectrum is to provide explicit ACLs on the node
>>per principal. It's ok for us to go this way... but we ended up with
>>an open question on the subject the mail. Do we know how ACL
>>evaluation performance behave wrt number-of-ACLs on a node - assuming
>>ACLs-per-principal won't be a big number?
>
> The access control content as stored with the individual nodes in ACLs
> and ACEs is _not_ used for the evaluation at all. Permission evaluation
> and thus performance of permission evaluation of the default authorization
> model is purely defined by the performance of compiling effective
> permissions from the data stored in the permission store at
> /jcr:system/rep:permissionStore.
>
> In other words: the permission evaluation is based on the following
> pieces:
>
> 1. the set of principals as pushed to the subject upon authentication
> 2. permission-entries stored separately for each principal in the
> perm-store
> 3. separation of the 2 types of principals as defined by java (Principal
> and java.security.acl.Group)
>
> Based on the original design goals we laid out for Oak promising that
> flat hierarchies of non-ordered nodes is supported, I would not expect
> issues with a huge amount of permission entries in the store for a single
> principal.

That's good to know :). So, unless we're talking about editing
permissions on the node, it should be ok for having large number of
ACL/Es.

>
> On the other hand: access control entries as edited by the default
> user facing access control management implementation are collected in
> a list which be definition has an order. this is reflected by the
> content structure storing ACEs as nodes below a policy node that is defined
> to have orderable children. Since support for huge flat hierarchies
> of _orderable_ nodes was a explicit non-goal of Oak, I would expect
> to see limitations here when it comes to tens of thousands of ACEs
> for a given single ACL.

Good point. This reminds me that we might also hit document size limit
(or maybe not!!) as :childorder is a single array and huge value can
befuddle mongomk in some cases (e.g. OAK-4322.. but then 16MB is a big
number)


> My take is: if a given application ends up with
> tens of thousands of access control entries within a given list this
> may either highlight design issues with the content modelling wrt
> security or it may give us a hint that a different authorization model
> might be more suited for that use-case.

I posted a few details on the use-case a bit above in this reply.
Would you please comment on how to have persona based authorization
for say some flat content structure. As an analogy, I can think of say
google docs... how should one go about managing content structure and
privileges. It might be a digression on this thread. I'd be happy to
fork this discussion out.

>
>>I was thinking of writing a benchmark to see but wanted to copy some
>>closely related existing benchmark. It'd great if there are some
>>pointers for this 

Re: How does having lot of ACL (for different principals) on a single node affect performance

[Angela Schreiber]

Hi Vikas

Here some input to the different topics|questions raised below.

On 24/10/16 17:01, "Vikas Saurabh"  wrote:

>Hi,
>
>In a project I'm working, we have a some personas which represent the
>kind of operations member of those personas are allowed to do over a
>given node.
>
>The most trivial idea was to have a
>synthetic-group-per-persona-per-such-node and add/remove members to
>these groups. This approach has obvious side-effects:
>* systems gets flooded with system-generated-groups thus requiring
>special UI for user/group management

Are you talking about real users/groups as defined by the Jackrabbit
user management or about simple principals as we discussed during the
last Oakathon? For the latter the UI is limited to crx-explorer which
is the only UI Adobe provides that exposes the principal management UI.

>* can potentially affect login performance - I haven't checked how
>OAK-3003 works.. maybe, it's a non-issue

Without knowing the exact details of your use-case: depending on how your
synthetic-groups are envisioned to work and whether or not this member
is really intended to be edited and managed through the CQ user management
UI, you may consider solving this with principal management rather than
user management... see above and also referring to the conversation
we had last time.

>* eerie feeling to require additional groups :)
>
>The other end of the spectrum is to provide explicit ACLs on the node
>per principal. It's ok for us to go this way... but we ended up with
>an open question on the subject the mail. Do we know how ACL
>evaluation performance behave wrt number-of-ACLs on a node - assuming
>ACLs-per-principal won't be a big number?

The access control content as stored with the individual nodes in ACLs
and ACEs is _not_ used for the evaluation at all. Permission evaluation
and thus performance of permission evaluation of the default authorization
model is purely defined by the performance of compiling effective
permissions from the data stored in the permission store at
/jcr:system/rep:permissionStore.

In other words: the permission evaluation is based on the following
pieces:

1. the set of principals as pushed to the subject upon authentication
2. permission-entries stored separately for each principal in the
perm-store
3. separation of the 2 types of principals as defined by java (Principal
and java.security.acl.Group)

Based on the original design goals we laid out for Oak promising that
flat hierarchies of non-ordered nodes is supported, I would not expect
issues with a huge amount of permission entries in the store for a single
principal.

On the other hand: access control entries as edited by the default
user facing access control management implementation are collected in
a list which be definition has an order. this is reflected by the
content structure storing ACEs as nodes below a policy node that is defined
to have orderable children. Since support for huge flat hierarchies
of _orderable_ nodes was a explicit non-goal of Oak, I would expect
to see limitations here when it comes to tens of thousands of ACEs
for a given single ACL. My take is: if a given application ends up with
tens of thousands of access control entries within a given list this
may either highlight design issues with the content modelling wrt
security or it may give us a hint that a different authorization model
might be more suited for that use-case.

>I was thinking of writing a benchmark to see but wanted to copy some
>closely related existing benchmark. It'd great if there are some
>pointers for this :).

There are some authorization related benchmarks and Alex Collignon
will provide some additional in the light of OAK-5025.

As far as login-performance is concerned there are quite some benchmarks
available for the different topics involved with authentication such as
e.g.
- GetGroupPrincipalsTest where you could verify OAK-3003
- in the authentication.external package benchmarks illustrating what the
  performance with the 'dynamic group membership' would look like compared
  to full sync intro the repositories user management
- membership related benchmarks
- pure login benchmarks for various types of principals

If you are looking for specific benchmarks or need help writing one,
let me know.

Hope that helps
angela

>
>Thanks,
>Vikas

Re: How does having lot of ACL (for different principals) on a single node affect performance

[Michael Marth]

Here are some benchmarks, some of the on benchmarking access control 
performance:
https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/benchmark

HTH
Michael




On 24/10/16 17:01, "Vikas Saurabh"  wrote:

>Hi,
>
>In a project I'm working, we have a some personas which represent the
>kind of operations member of those personas are allowed to do over a
>given node.
>
>The most trivial idea was to have a
>synthetic-group-per-persona-per-such-node and add/remove members to
>these groups. This approach has obvious side-effects:
>* systems gets flooded with system-generated-groups thus requiring
>special UI for user/group management
>* can potentially affect login performance - I haven't checked how
>OAK-3003 works.. maybe, it's a non-issue
>* eerie feeling to require additional groups :)
>
>The other end of the spectrum is to provide explicit ACLs on the node
>per principal. It's ok for us to go this way... but we ended up with
>an open question on the subject the mail. Do we know how ACL
>evaluation performance behave wrt number-of-ACLs on a node - assuming
>ACLs-per-principal won't be a big number?
>
>I was thinking of writing a benchmark to see but wanted to copy some
>closely related existing benchmark. It'd great if there are some
>pointers for this :).
>
>Thanks,
>Vikas

How does having lot of ACL (for different principals) on a single node affect performance

[Vikas Saurabh]

Hi,

In a project I'm working, we have a some personas which represent the
kind of operations member of those personas are allowed to do over a
given node.

The most trivial idea was to have a
synthetic-group-per-persona-per-such-node and add/remove members to
these groups. This approach has obvious side-effects:
* systems gets flooded with system-generated-groups thus requiring
special UI for user/group management
* can potentially affect login performance - I haven't checked how
OAK-3003 works.. maybe, it's a non-issue
* eerie feeling to require additional groups :)

The other end of the spectrum is to provide explicit ACLs on the node
per principal. It's ok for us to go this way... but we ended up with
an open question on the subject the mail. Do we know how ACL
evaluation performance behave wrt number-of-ACLs on a node - assuming
ACLs-per-principal won't be a big number?

I was thinking of writing a benchmark to see but wanted to copy some
closely related existing benchmark. It'd great if there are some
pointers for this :).

Thanks,
Vikas