Hi Julian, > On 26 Jun 2018, at 09:25, Julian Sedding <[email protected]> wrote: > > Hi Bertrand > > On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz > <[email protected] <mailto:[email protected]>> wrote: >> Hi Julian, >> >> On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding <[email protected]> wrote: >>> Regarding securing the servlet: >>> Registering a servlet in Sling creates resources. In the case of the >>> capabilities servlet, that should be the resource >>> "/libs/sling/capabilities.json.GET.servlet". Since the "Resource >>> Access Security" module allows restricting read access to resources, >>> this could be used to secure the servlet... >> >> Yes, but that only works for servlet, I think if we agree on a >> (simple) mechanism to secure arbitrary operations, as Radu suggest, >> it's more flexible. > > Why do you say that only works for servlets? Sling's rendering script > resolution is entirely built on topof the resource abstraction. That > is the reason that servlets are part of the resource tree in the first > place. This in turn leads to the (IMHO desirable) property that > "Scripts and Servlets are equal"[0]. > > [0] > https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#fundamental-scripts-and-servlets-are-equal > > <https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#fundamental-scripts-and-servlets-are-equal> > >> >> And I'd like this to be backed by Oak so we can take advantage of its >> proven access control features, including management tools. > > Using "Resource Access Security" in order to restrict access to the > resource type does not prevent you from implementing a > ResourceAccessGate[1] based on (protected) nodes in Oak. > > The advantages of protecting visibility of the servlet/script that I propose > - solves the problem at the root > - does not require changes to the servlet/script implementation > - because it is entirely orthogonal > > [1] > https://sling.apache.org/documentation/bundles/resource-access-security.html#how-to-implement-resourceaccessgate > > <https://sling.apache.org/documentation/bundles/resource-access-security.html#how-to-implement-resourceaccessgate> >
Isn’t this a chicken and egg problem? You have to register a servlet in order to have the resource you meant created by the engine. How would you define the ACLs? I guess you were not thinking of hardcoding access rules in a ResourceAccessGate but rather delegating to Oak. However AFAIK you cannot create an ACL without already having the path in the repository, unless you’d define the ACLs higher in the tree and then rely on glob patterns. Can you please help me understand the solution? Thanks, Radu
