I guess it would help if some use cases where listed here. Atm I'm a little bit unclear what this proposal is trying to solve?
Regards Carsten Eric Norman wrote > 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 > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
