Hi,
A recent thread [0] presented the idea of adding a more generic mechanism to
restrict the execution of certain servlets, based on capabilities; however, we
didn’t reach any consensus.
Several suggestions were presented, based on providing additional
ResourceProviders or implementing ResourceAccessGates, but we never got
anywhere and I think that neither of those two approaches are complete.
Servlets do create Sling resources, but that’s not applicable to scripts
deployed in the search paths. IMO, we’d need one central place where we
evaluate resource type execution permission and this should happen in the
org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t think
we’d need a new external API for now, hence why I’d limit the implementation to
something very simple:
1. Create a /system/permissions protected resource (restrict access based on
ACLs)
2. Define permissions that can be added: e.g.
/system/permissions/sling:resourceType
3. Define resource types that need to be protected: e.g.
/system/permissions/sling:resourceType/org/acme/weather
4. Define ACLs that govern who can execute a certain resource type: e.g.
/system/permissions/sling:resourceType/org/acme/weather/rep:policy where we’d
whitelist (allow) reading (jcr:read) for certain principals
5. In the ServletResolver check the current resource type, find its mapping in
/system/permissions/sling:resourceType and see if the current user can read it
(Resource API)
5.1. If the user can read it, continue with the regular flow of servlet
resolution - the user is allowed to execute the current resource type
5.2. If not, there are two options:
5.2.1. the resource exists (check with a higher privileged user), which
means that the current user should not be allowed to execute whatever’s mapped
behind the resource type
5.2.2. the resource doesn’t exist, which means that the resource type
is not protected, so we continue with the normal servlet resolution phase
In this way we’d delegate all the checks to the ResourceProviders. The
persistence mechanism that Sling uses would define what and how can be
accessed, given that Sling has no other way to enforce Resource access control
- the ResourceAccessGate API seems incomplete. It’s important to note that this
implementation would be based though on content structures, which have to be
stable. As soon as we have to change the structure we introduce breaking
changes, which will not be easy to handle.
Thoughts?
Thanks,
Radu
[0] -
https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E
