Is it the resource type that needs protection? Or the script/servlet that is handling a specific method+selector+extension for the resource type?
I generally prefer to have all my servlets get called regardless of whether the user has rights to do that action so any invalid requests can be handled in a consistent manner and I can block passing off the handling to other unknown handlers. A servlet (or filter) can easily do access checks in java code at the beginning of the handler and send the appropriate error response if the user doesn't have the right privileges. And we already have the OptingServlet interface for servlets which may choose to not handle all requests for which they would be selected if you want the handling to fall through. For my own projects, I used to do access checking in each "esp" script, but after migrating to from "esp" to "htl" scripts some refactoring was required and this is what I came up with: 1. To handle POST requests, each servlet does it's own access checking in java code to ensure the right privileges are granted before any processing happens. 2. To handle GET requests I utilize two generic filters whose configuration is supplied by other multiple "config" OSGi services: a) SelectorWhitelistFilter - block access to any unexpected selectors. A SelectorWhitelist configuration OSGi service is registered for each resource type to declare which selectors are allowed for each resource type. b) BlockNotAuthorizedFilter - for selectors that get past #1, check permissions and block access for users who don't have the required privileges. A NotAuthorized OSGi service is registered for each family of scripts to do the appropriate checks. The code was pretty simple and I could probably share it if anyone is interested. Regards, -Eric On Wed, Oct 3, 2018 at 4:57 AM Radu Cotescu <[email protected]> wrote: > 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
