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" <vikas.saur...@gmail.com> 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 "<viewer>" >and "<editor>". Where <viewer> (or <editor>) is essentially a >"synonym" of what type of privileges do <viewer>s have (it might be >more that read... it might be read on current node + some more privs >for content-structure under it. >All <viewers> need to have same type of access on the content. >Similarly <editor> 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 <viewer>, <editor>, 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 :). >> >> 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. > >I couldn't work on this one recently... but here's a benchmark model I >had in mind: >---- >Benchmark variable -> N > >N users > >/test (deny:all:everyone) >- /childX (X=1 to NODE_COUNT) (allow:all:userY (Y=1 to N)) #so, each >node has N ACE allowing all to each user > >ReadTest >- loginWithUser1 >- count reads of /test/childX by User1 (X=random(1 to NODE_COUNT)) > >AdminReadTest >- loginWithAdmin >- count reads of /test/childX by admin (X=random(1 to NODE_COUNT)) > >WriteTest >- loginWithUser1 >- count write to /test/childX by User1 (X=random(1 to NODE_COUNT)) > >AdminWriteTest >- loginWithAdmin >- count write to /test/childX by admin (X=random(1 to NODE_COUNT)) > >ACLCreateTest >- loginWithUser1 >- count acl modification of /test/childX by User1 (X=random(1 to >NODE_COUNT)) > >AdminACLCreateTest >- loginWithAdmin >- count acl modification of /test/childX by admin (X=random(1 to >NODE_COUNT)) >------ > >Ideas for what else might be useful to observe would be great :). > >> >> Hope that helps >> angela >> > >Thanks, >Vikas
