Hi Bertrand, > On 25 Jun 2018, at 18:26, Bertrand Delacretaz <[email protected]> wrote: > > On Fri, Jun 22, 2018 at 3:03 PM Radu Cotescu <[email protected] > <mailto:[email protected]>> wrote: >> ...So what we could do is to combine the two ideas: >> >> Have >> /sling/operations >> resourceType1 >> ACLs / CUG [0] >> resourceType2 >> ACLs / CUG [0] >> >> And evaluate them similar to the previous algorithm.... > > So the ACLs/CUG items above would the be names of Principals who can > execute that operation? > > I'm not sure why that indirection is needed: if I want to execute a > /sling/capabilities/someCaps operation, I might simply call a > Permissions service that adds a a configurable prefix to that path, > ends up with (say) /libs/sling/permissions/sling/capabilities/someCaps > and if that resource exists and the current user can read it grants > the permission.
I don’t understand what you mean by indirection and I start having the impression that we both proposed the same concept, but using a different vocabulary: you said “capabilities”, I said “operations”. In the end we are both talking about yet another resource where we test the applied ACLs / CUGs, to figure out if the capability / operation can be read / executed by a certain user. The ACLs / CUGs are not the node names, but the node types (e.g. rep:Policy). Regards, Radu
