Hi Julian, the "traditional" way to bind a servlet to the resource tree is to create a resource with the respective resource type. And because in "traditional" setups we most often had backed our resource tree by a JCR repo, so creating a node with the correct resource type property was the way to go. And restricting access to that servlet can then be implemented by restricting access to the JCR node by the means of JCR access control. But I understand that you are speaking of Resource Access Security, which does not rely on JCR access control, but can be applied independently of it, on a pure Sling Resource level.
Is that correct? In my understanding, it doesn't matter which approach we choose (JCR access control or Resource Access Security), limiting access to a servlet should not be a concern of the servlet; I fully agree to Julian's position here. Jörg 2018-06-27 13:23 GMT+00:00 Julian Sedding <jsedd...@gmail.com>: > 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 > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
