Hi Bertrand,
We’ve had an offline discussion a few months back about the possibility of
creating an "operations table” in Sling which would allow to whitelist
principals that are allowed to execute scripts / servlets bound to certain
resource types. IIRC the idea was to have something like:
|Operation (resource type) |Principals |
|-------------------------------|-------------------------------|
|a.b.c | administrators |
|sling/capabilities | operations |
Then, when the Servlet Resolver attempts to figure out which servlet / script
is supposed to be executed for a certain resource, the resolver would first
check the operations table to figure out if the current operation is there:
If it is, it would check
if the current user is included in the list of principals for
that operation or if any of those principals includes the user (groups).
if not, return a 403, even if the current user is allowed to
read the resource
Else run like before
After talking to Alex (in CC), I found out that expanding the Principals from
this table to figure out if the current user is included would be too costly.
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. If things get slow because
of the extra repository reads (one with a privileged user to figure out if the
operation is protected or not, another with the current user, only if the
operation exists, to determine is the user is allowed to execute it), we could
cache the results after the first eval assuming an ACL change would change the
whole instance (Sling instances should be like cattle).
This approach would make this protection mechanism globally available in Sling.
WDYT?
Regards,
Radu
P.S. Friday discussions are the best!
[0] - https://jackrabbit.apache.org/oak/docs/security/authorization/cug.html
<https://jackrabbit.apache.org/oak/docs/security/authorization/cug.html>
> On 22 Jun 2018, at 11:17, Bertrand Delacretaz <[email protected]> wrote:
>
> What I'm suggesting is that the servlet always checks a resource at a
> configurable path, like /sling/permissions/capabilities/read, and
> returns a 403 forbidden status if the current user cannot read that
> resource.
>
> The /sling/permissions path is suitably protected so that non-admin
> users cannot write under it.
