Hi Vikas Here some input to the different topics|questions raised below.
On 24/10/16 17:01, "Vikas Saurabh" <[email protected]> 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
