Hi Joerg, Even when a servlet is bound by resource type, it still assigned a resource entry. If you look at /system/console/status-jcrresolver (which is incorrectly named, but that's another story) on a running Sling instance with some servlets installed, you'll see entries for each servlet under a path like /libs/<resource type>.<method>.servlet (or something like that).
Looking at this specific case, I'm now thinking that the implementation of a servlet here is non-idiomatic. It would be better (at least from my perspective), if this was all handled via ResourceProvider (e.g. mounted at /system/sling/capabilities or some such) and each CapabilitySource resulted in a child resource (the ResourceProvider could/should handle the creation of the synthetic resource; it doesn't have to be part of the CapabilitiesSource SPI). Then a request to /system/sling/capabilities.infinity.json would return all the capabilities and a request to /system/sling/capabilities/<namespace>.json would return just a single capability. No servlet is actually necessary -- the default GET servlet will handle the serialization. This would, I think, obviate the need for some of this discussion about access control since it becomes obvious that Resource Access Security is the correct approach as securing non-JCR Resource Providers is the original use case for Resource Access Security (at least if my fragile memory serves). @Bertrand - is there a reason you went with a single servlet implementation vs. having each capability source be its own resource? On Wed, Jun 27, 2018 at 1:42 PM Jörg Hoh <[email protected]> wrote: > 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 <[email protected]>: > > > 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 <[email protected]> wrote: > > > 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 > > > > > > -- > Cheers, > Jörg Hoh, > > http://cqdump.wordpress.com > Twitter: @joerghoh >
