E.g. requesting /libs/sling/servlet/default/GET.servlet.tidy.-1.json
on a Sling instance returns the following JSON view of the servlet
registration resource:
{
"sling:resourceSuperType": "sling/bundle/resource",
"servletClass": "org.apache.sling.servlets.get.impl.DefaultGetServlet",
"sling:resourceType": "/libs/sling/servlet/default/GET.servlet",
"servletName": "org.apache.sling.servlets.get.DefaultGetServlet"
}
Hence, implementing a ResourceAccessGate that checks for the presence
of a node matching servletClass (or servletName) an validates required
permissions should be relatively simple.
This solution would be completely independent of the servlet
implementation and could therefore easily be retro-fitted, even to 3rd
party code. Furthermore, it protects access to the servlet rather than
an HTTP endpoint through which the servlet may be executed. Thus there
should be less ways to circumvent the protection. E.g. creating a
resource with a matching resource type will then not allow a user to
execute the servlet.
Regards
Julian
On Wed, Jun 27, 2018 at 3:23 PM, Julian Sedding <[email protected]> wrote:
> 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
