Hi Radu Internally, every Servlet registered by resource type in Sling is exposed at one (or several) locations in the Resource tree (!= JCR Node tree).
ResourceAccessGate is a pluggable API that allows preventing read access to arbitrary resources. Therefore it is possible to prevent access to the resource(s) that represent the Servlet. Whether the actual ResourceAccessGate implementation uses JCR/Oak internally is irrelevant on a conceptual level. On a practical level it may be desirable and it is certainly possible. The implementation could choose an arbitrary convention, e.g. permissions could be checked at /apps/servlets/org.example.BackDoorServlet for org.example.BackDoorServlet. I hope this helps clarify the concept :) Regards Julian On Wed, Jun 27, 2018 at 1:58 PM, Radu Cotescu <r...@apache.org> wrote: > Hi Julian, > >> On 26 Jun 2018, at 09:25, Julian Sedding <jsedd...@gmail.com> wrote: >> >> Hi Bertrand >> >> On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz >> <bdelacre...@apache.org <mailto:bdelacre...@apache.org>> wrote: >>> Hi Julian, >>> >>> On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding <jsedd...@gmail.com> 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
