Re: [sling:resourceType] protected execution
Yes, I think that covers it, with the addition that 1. should also cover sling:resourceSuperType And the solution should not have a negative impact on the runtime performance of request executions. Regards Carsten Am 15.10.2018 um 11:10 schrieb Radu Cotescu: Hi Carsten, So then the requirements should be: 1. Protect the creation of the sling:resourceType property 2. Provide granular permissions for which resource type / selector & extension / HTTP method we allow the execution of a script / servlet and code to enforce them in either the servlet resolution phase or servlet execution 3. Make sure that restrictions can work within the resource type hierarchy Did I miss something? Thanks, Radu On 7 Oct 2018, at 10:16, Carsten Ziegeler wrote: I agree with Eric here, independent of the how we protect the execution, we should also tackle the initial problem that everyone with write access can set any resource type. It seems strange that we invite everyone with weapons into our house and then try to prevent them from using it. We should keep them out in the first place. I also think that a mechanism purely working resource types is not exactly what we need. Think about you have a "view" and an "execute" script for a resource type (potentially attached to selectors). Users may be able to use the "view" script but "execute" is more protected. Then we have the resource type hierarchy, so if I'm able to set a resource type I can also set a resource super type. We need to make sure that this does not open something we wanted to close. I think the current proposals cover this, but it should be verified. So all in all, I think this problem is more complex than just adding a service with a single method and pretend that everything else are implementation details. Regards Carsten Eric Norman wrote 1. Users can freely define sling:resourceType properties Is there some reason why this must be so? In JCR land, the jcr:nodeTypeManagement privilege must be granted for the user to have permission to add and remove mixin node types and change the primary node type of a node. I would expect that a similar elevated privilege could protect against unwanted modifications of the sling:resourceType values by the wrong users. For #2 and #3, perhaps what you are really describing is a mechanism for defining and checking what I would call "functional privileges"? In other words, not the same as permissions on the data, but permissions on the action. Would it be necessary to associate those "functional privileges" to a resource type? I can imagine you may want to define a "functional privilege" that could be checked by some servlet/filter/component/osgi_service/model/other that works for many different resource types or no specific resource type at all. For example, 1. Imagine a resource defined at "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" permissions determines if the user can perform the "usage_report" servlet action. 2. Then the "usage_report" servlet simply has to has to check if the "yourapp/usage_report" resource at #1 exists for the current user (or some higher level API that does the same) to know if the servlet should proceed or return an error code. 3. For scripts, perhaps a sling:functionalPrivilege property on the resource could define what is required and block the script processing generically when those conditions are not satisfied. That's my 2 cents.. Regards, -Eric On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: Hi, Since this thread exploded so quickly it’s going to be difficult to respond to all of your questions / concerns individually. We eagerly started discussing implementation details (of which I’m to blame too) and I think we didn’t read between the lines of this thread or the previous [0] to check what the perceived problems are. Both threads identified several issues: 1. Users can freely define sling:resourceType properties 2. Through 1, users can therefore trigger code execution which is not always appropriate (depends on how Servlets / scripts are written and the potential they have to DoS a system or to expose sensible information to users which shouldn’t have the ability to perform those operations) 3. For some operations (servlet execution, tasks, etc.) we might want to provide a set of permissions to check beforehand in order to decide if a user is allowed to perform said operation or not. In this thread I proposed an idea to fix issue no. 2 (which IMO is easier to accomplish) - and by fix I mean provide a way to define who can execute what - so that we don’t care about issue no. 1 any more. Let’s try to figure out if indeed these are some serious problems that need to be addressed or not. We can discuss implementation details afterwards. Cheers, Radu -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
Hi Carsten, So then the requirements should be: 1. Protect the creation of the sling:resourceType property 2. Provide granular permissions for which resource type / selector & extension / HTTP method we allow the execution of a script / servlet and code to enforce them in either the servlet resolution phase or servlet execution 3. Make sure that restrictions can work within the resource type hierarchy Did I miss something? Thanks, Radu > On 7 Oct 2018, at 10:16, Carsten Ziegeler wrote: > > I agree with Eric here, independent of the how we protect the execution, > we should also tackle the initial problem that everyone with write > access can set any resource type. It seems strange that we invite > everyone with weapons into our house and then try to prevent them from > using it. We should keep them out in the first place. > > I also think that a mechanism purely working resource types is not > exactly what we need. Think about you have a "view" and an "execute" > script for a resource type (potentially attached to selectors). Users > may be able to use the "view" script but "execute" is more protected. > > Then we have the resource type hierarchy, so if I'm able to set a > resource type I can also set a resource super type. We need to make sure > that this does not open something we wanted to close. I think the > current proposals cover this, but it should be verified. > > So all in all, I think this problem is more complex than just adding a > service with a single method and pretend that everything else are > implementation details. > > Regards > > Carsten > > > Eric Norman wrote >>> >>> 1. Users can freely define sling:resourceType properties >> >> >> Is there some reason why this must be so? In JCR land, the >> jcr:nodeTypeManagement privilege must be granted for the user to have >> permission to add and remove mixin node types and change the primary node >> type of a node. I would expect that a similar elevated privilege could >> protect against unwanted modifications of the sling:resourceType values by >> the wrong users. >> >> >> For #2 and #3, perhaps what you are really describing is a mechanism for >> defining and checking what I would call "functional privileges"? In other >> words, not the same as permissions on the data, but permissions on the >> action. Would it be necessary to associate those "functional privileges" >> to a resource type? I can imagine you may want to define a "functional >> privilege" that could be checked by some >> servlet/filter/component/osgi_service/model/other that works for many >> different resource types or no specific resource type at all. >> >> For example, >> 1. Imagine a resource defined at >> "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" >> permissions determines if the user can perform the "usage_report" servlet >> action. >> 2. Then the "usage_report" servlet simply has to has to check if the >> "yourapp/usage_report" resource at #1 exists for the current user (or some >> higher level API that does the same) to know if the servlet should proceed >> or return an error code. >> 3. For scripts, perhaps a sling:functionalPrivilege property on the >> resource could define what is required and block the script processing >> generically when those conditions are not satisfied. >> >> That's my 2 cents.. >> >> Regards, >> -Eric >> >> >> On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: >> >>> Hi, >>> >>> Since this thread exploded so quickly it’s going to be difficult to >>> respond to all of your questions / concerns individually. We eagerly >>> started discussing implementation details (of which I’m to blame too) and I >>> think we didn’t read between the lines of this thread or the previous [0] >>> to check what the perceived problems are. >>> >>> Both threads identified several issues: >>> 1. Users can freely define sling:resourceType properties >>> 2. Through 1, users can therefore trigger code execution which is not >>> always appropriate (depends on how Servlets / scripts are written and the >>> potential they have to DoS a system or to expose sensible information to >>> users which shouldn’t have the ability to perform those operations) >>> 3. For some operations (servlet execution, tasks, etc.) we might want to >>> provide a set of permissions to check beforehand in order to decide if a >>> user is allowed to perform said operation or not. >>> >>> In this thread I proposed an idea to fix issue no. 2 (which IMO is easier >>> to accomplish) - and by fix I mean provide a way to define who can execute >>> what - so that we don’t care about issue no. 1 any more. >>> >>> Let’s try to figure out if indeed these are some serious problems that >>> need to be addressed or not. We can discuss implementation details >>> afterwards. >>> >>> Cheers, >>> Radu >>> >>> >>> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [sling:resourceType] protected execution
My understanding of this thread is that it is about "controlling execution of servlets/scripts pertaining to individual resource-types". Carsten's point that we may want more fine-grained control, i.e. differentiate between "view" and "execute" (which may often be GET and POST), sounds sensible. Therefore it makes sense to me to include this requirement in the discussion. So far I am not convinced that any new API is needed to achieve this. And am therefore opposed to any solution that proposes/requires a new API. I see two existing APIs, which could help: - ResourceAccessGate - which I feel that some in this discussion don't understand how it could relate to resource-types and so far I seem to have failed to explain it properly - ResourceDecorator - we could "decorate-away" resource types that a user is not allowed to see, or even substitute them to render an error message instead. Via resource.getResourceResolver().getUserID() we have access to the current user. For any of these mechanisms to work, the script-user may be a hindrance. But I believe it would be worthwhile exploring if we cannot change this in a way that allows the approach to work. Regards Julian On Sun, Oct 7, 2018 at 8:17 AM Carsten Ziegeler wrote: > > I agree with Eric here, independent of the how we protect the execution, > we should also tackle the initial problem that everyone with write > access can set any resource type. It seems strange that we invite > everyone with weapons into our house and then try to prevent them from > using it. We should keep them out in the first place. > > I also think that a mechanism purely working resource types is not > exactly what we need. Think about you have a "view" and an "execute" > script for a resource type (potentially attached to selectors). Users > may be able to use the "view" script but "execute" is more protected. > > Then we have the resource type hierarchy, so if I'm able to set a > resource type I can also set a resource super type. We need to make sure > that this does not open something we wanted to close. I think the > current proposals cover this, but it should be verified. > > So all in all, I think this problem is more complex than just adding a > service with a single method and pretend that everything else are > implementation details. > > Regards > > Carsten > > > Eric Norman wrote > >> > >> 1. Users can freely define sling:resourceType properties > > > > > > Is there some reason why this must be so? In JCR land, the > > jcr:nodeTypeManagement privilege must be granted for the user to have > > permission to add and remove mixin node types and change the primary node > > type of a node. I would expect that a similar elevated privilege could > > protect against unwanted modifications of the sling:resourceType values by > > the wrong users. > > > > > > For #2 and #3, perhaps what you are really describing is a mechanism for > > defining and checking what I would call "functional privileges"? In other > > words, not the same as permissions on the data, but permissions on the > > action. Would it be necessary to associate those "functional privileges" > > to a resource type? I can imagine you may want to define a "functional > > privilege" that could be checked by some > > servlet/filter/component/osgi_service/model/other that works for many > > different resource types or no specific resource type at all. > > > > For example, > > 1. Imagine a resource defined at > > "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" > > permissions determines if the user can perform the "usage_report" servlet > > action. > > 2. Then the "usage_report" servlet simply has to has to check if the > > "yourapp/usage_report" resource at #1 exists for the current user (or some > > higher level API that does the same) to know if the servlet should proceed > > or return an error code. > > 3. For scripts, perhaps a sling:functionalPrivilege property on the > > resource could define what is required and block the script processing > > generically when those conditions are not satisfied. > > > > That's my 2 cents.. > > > > Regards, > > -Eric > > > > > > On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: > > > >> Hi, > >> > >> Since this thread exploded so quickly it’s going to be difficult to > >> respond to all of your questions / concerns individually. We eagerly > >> started discussing implementation details (of which I’m to blame too) and I > >> think we didn’t read between the lines of this thread or the previous [0] > >> to check what the perceived problems are. > >> > >> Both threads identified several issues: > >> 1. Users can freely define sling:resourceType properties > >> 2. Through 1, users can therefore trigger code execution which is not > >> always appropriate (depends on how Servlets / scripts are written and the > >> potential they have to DoS a system or to expose sensible information to > >> users which shouldn’t have the ability to perform those
Re: [sling:resourceType] protected execution
I agree with Eric here, independent of the how we protect the execution, we should also tackle the initial problem that everyone with write access can set any resource type. It seems strange that we invite everyone with weapons into our house and then try to prevent them from using it. We should keep them out in the first place. I also think that a mechanism purely working resource types is not exactly what we need. Think about you have a "view" and an "execute" script for a resource type (potentially attached to selectors). Users may be able to use the "view" script but "execute" is more protected. Then we have the resource type hierarchy, so if I'm able to set a resource type I can also set a resource super type. We need to make sure that this does not open something we wanted to close. I think the current proposals cover this, but it should be verified. So all in all, I think this problem is more complex than just adding a service with a single method and pretend that everything else are implementation details. Regards Carsten Eric Norman wrote >> >> 1. Users can freely define sling:resourceType properties > > > Is there some reason why this must be so? In JCR land, the > jcr:nodeTypeManagement privilege must be granted for the user to have > permission to add and remove mixin node types and change the primary node > type of a node. I would expect that a similar elevated privilege could > protect against unwanted modifications of the sling:resourceType values by > the wrong users. > > > For #2 and #3, perhaps what you are really describing is a mechanism for > defining and checking what I would call "functional privileges"? In other > words, not the same as permissions on the data, but permissions on the > action. Would it be necessary to associate those "functional privileges" > to a resource type? I can imagine you may want to define a "functional > privilege" that could be checked by some > servlet/filter/component/osgi_service/model/other that works for many > different resource types or no specific resource type at all. > > For example, > 1. Imagine a resource defined at > "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" > permissions determines if the user can perform the "usage_report" servlet > action. > 2. Then the "usage_report" servlet simply has to has to check if the > "yourapp/usage_report" resource at #1 exists for the current user (or some > higher level API that does the same) to know if the servlet should proceed > or return an error code. > 3. For scripts, perhaps a sling:functionalPrivilege property on the > resource could define what is required and block the script processing > generically when those conditions are not satisfied. > > That's my 2 cents.. > > Regards, > -Eric > > > On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: > >> Hi, >> >> Since this thread exploded so quickly it’s going to be difficult to >> respond to all of your questions / concerns individually. We eagerly >> started discussing implementation details (of which I’m to blame too) and I >> think we didn’t read between the lines of this thread or the previous [0] >> to check what the perceived problems are. >> >> Both threads identified several issues: >> 1. Users can freely define sling:resourceType properties >> 2. Through 1, users can therefore trigger code execution which is not >> always appropriate (depends on how Servlets / scripts are written and the >> potential they have to DoS a system or to expose sensible information to >> users which shouldn’t have the ability to perform those operations) >> 3. For some operations (servlet execution, tasks, etc.) we might want to >> provide a set of permissions to check beforehand in order to decide if a >> user is allowed to perform said operation or not. >> >> In this thread I proposed an idea to fix issue no. 2 (which IMO is easier >> to accomplish) - and by fix I mean provide a way to define who can execute >> what - so that we don’t care about issue no. 1 any more. >> >> Let’s try to figure out if indeed these are some serious problems that >> need to be addressed or not. We can discuss implementation details >> afterwards. >> >> Cheers, >> Radu >> >> >> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
> > 1. Users can freely define sling:resourceType properties Is there some reason why this must be so? In JCR land, the jcr:nodeTypeManagement privilege must be granted for the user to have permission to add and remove mixin node types and change the primary node type of a node. I would expect that a similar elevated privilege could protect against unwanted modifications of the sling:resourceType values by the wrong users. For #2 and #3, perhaps what you are really describing is a mechanism for defining and checking what I would call "functional privileges"? In other words, not the same as permissions on the data, but permissions on the action. Would it be necessary to associate those "functional privileges" to a resource type? I can imagine you may want to define a "functional privilege" that could be checked by some servlet/filter/component/osgi_service/model/other that works for many different resource types or no specific resource type at all. For example, 1. Imagine a resource defined at "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" permissions determines if the user can perform the "usage_report" servlet action. 2. Then the "usage_report" servlet simply has to has to check if the "yourapp/usage_report" resource at #1 exists for the current user (or some higher level API that does the same) to know if the servlet should proceed or return an error code. 3. For scripts, perhaps a sling:functionalPrivilege property on the resource could define what is required and block the script processing generically when those conditions are not satisfied. That's my 2 cents.. Regards, -Eric On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: > Hi, > > Since this thread exploded so quickly it’s going to be difficult to > respond to all of your questions / concerns individually. We eagerly > started discussing implementation details (of which I’m to blame too) and I > think we didn’t read between the lines of this thread or the previous [0] > to check what the perceived problems are. > > Both threads identified several issues: > 1. Users can freely define sling:resourceType properties > 2. Through 1, users can therefore trigger code execution which is not > always appropriate (depends on how Servlets / scripts are written and the > potential they have to DoS a system or to expose sensible information to > users which shouldn’t have the ability to perform those operations) > 3. For some operations (servlet execution, tasks, etc.) we might want to > provide a set of permissions to check beforehand in order to decide if a > user is allowed to perform said operation or not. > > In this thread I proposed an idea to fix issue no. 2 (which IMO is easier > to accomplish) - and by fix I mean provide a way to define who can execute > what - so that we don’t care about issue no. 1 any more. > > Let’s try to figure out if indeed these are some serious problems that > need to be addressed or not. We can discuss implementation details > afterwards. > > Cheers, > Radu > > >
Re: [sling:resourceType] protected execution
Hi Bertrand, > On 5 Oct 2018, at 16:18, Bertrand Delacretaz wrote: > > Hi, > > On Fri, Oct 5, 2018 at 2:47 PM Jason E Bailey wrote: >> ...1. Each resource provider, if it supports security, should be responsible >> for security... > > I think there are misunderstandings in this thread about what we're > trying to achieve. > > Radu, correct me if I'm wrong but I think the only aspect of your > proposal that we need to agree upon right now is to create a service > that provides an API like > > /** Throw a PermissionDeniedException if any of the requested > permissions is not granted > * in the context of the supplied ResourceResolver which points to > a specific user */ > void checkAllPermissions( > ResourceResolver context, > String ...requestedPermission) >throws PermissionDeniedException; > > The goal being to define permissions for things which are not content > - like letting a specific user execute any code that's tied to a > particular resource type, without having to implement checks in all > the affected code and scripts. > > How these permissions are configured and evaluated is an > implementation detail that we can discuss separately. > > I think Radu is proposing to keep this API internal to the servlets > resolver as we don't see a need for it outside of that for now. Yes, an internal API for now would be more than enough, since we have only one use-case. I’ve already started hacking on something [1] - it’s by no means neither ready, nor complete, but for now it seems to work and it’s only meant to show the idea. We could obviously transform my hack into something more generic, but if we’re only talking about this one use-case it might not be needed. > > Can we agree on this? If yes the remaining aspects can be addressed > separately in more specific discussions. > > -Bertrand Cheers, Radu [1] - https://github.com/apache/sling-org-apache-sling-engine/compare/resource-type-execution?expand=1
Re: [sling:resourceType] protected execution
Hi, On Fri, Oct 5, 2018 at 2:47 PM Jason E Bailey wrote: > ...1. Each resource provider, if it supports security, should be responsible > for security... I think there are misunderstandings in this thread about what we're trying to achieve. Radu, correct me if I'm wrong but I think the only aspect of your proposal that we need to agree upon right now is to create a service that provides an API like /** Throw a PermissionDeniedException if any of the requested permissions is not granted * in the context of the supplied ResourceResolver which points to a specific user */ void checkAllPermissions( ResourceResolver context, String ...requestedPermission) throws PermissionDeniedException; The goal being to define permissions for things which are not content - like letting a specific user execute any code that's tied to a particular resource type, without having to implement checks in all the affected code and scripts. How these permissions are configured and evaluated is an implementation detail that we can discuss separately. I think Radu is proposing to keep this API internal to the servlets resolver as we don't see a need for it outside of that for now. Can we agree on this? If yes the remaining aspects can be addressed separately in more specific discussions. -Bertrand
Re: [sling:resourceType] protected execution
I don't think we are all that far off from each other.
1. Each resource provider, if it supports security, should be responsible for
security
2. There should be a common interface to tell a resource provider what
permissions to be set.
3. I should be able to take a resource and if I have the privilege, determine
what permission restrictions are in force. This should work no matter what the
resource provider is.
And where I feel I'm really differing from others:
4. The permissions should be reflected within the context of the resources that
the resource provider provides. Much like how the jcr resource provider stores
acl as a rep:policy node. If I tell the servlet resource provider to that only
admin can get to any servlets under /content/custom/servlets/ that when I'm
using a resource browser to go down that tree, the resource provider adds
something like /content/custom/servlets/sling:policy that defines what was set.
What I don't want as a user is to have multiple locations to check to determine
what restrictions are being set for a given path. What I don't want as a
developer is to have multiple classes to deal with so that I have to create
restrictions differently if a user asks me to set a restriction on a resource.
I want magic
{mock}
SlingSecurity security = resource.adaptTo(SlingSecurity);
security.grantRead("bob")
for (SecurityRules rule: security.appliedRules()){
print(rules.toString());
}
{/end}
which would produce
admin / all *
set by jcr resourceProvider
sling-scripting / denyAll * set by jcr
resourceProvider
generic-users /custom read * set by file
resourceProvider
bob /custom/pathread* set by jasons
awesome customResourceProvider
Where I have a problem with Radu's original suggestion is that the permissions
are defined in a separate tree, I would have less of a problem with this, if
the resource providers checked this tree and echoed them out, or if multiple
resource providers used this tree as a common store of permissions. I don't
care so much then. I'm more concerned about the experience and the interface.
- Jason
On Fri, Oct 5, 2018, at 12:52 AM, Carsten Ziegeler wrote:
> Well, this will be a fun discussion :) Adding security on top of
> something is usually easier to be bypassed than having security built-in.
>
> But I would like to get briefly back to the use case of this "dangerous
> servlet". Why isn't that servlet doing the permission checks which I
> think is way safer than relying on additional magic somewhere else
> (regardless of what it is)?
>
> Regards
> Carsten
>
Re: [sling:resourceType] protected execution
Hi, Since this thread exploded so quickly it’s going to be difficult to respond to all of your questions / concerns individually. We eagerly started discussing implementation details (of which I’m to blame too) and I think we didn’t read between the lines of this thread or the previous [0] to check what the perceived problems are. Both threads identified several issues: 1. Users can freely define sling:resourceType properties 2. Through 1, users can therefore trigger code execution which is not always appropriate (depends on how Servlets / scripts are written and the potential they have to DoS a system or to expose sensible information to users which shouldn’t have the ability to perform those operations) 3. For some operations (servlet execution, tasks, etc.) we might want to provide a set of permissions to check beforehand in order to decide if a user is allowed to perform said operation or not. In this thread I proposed an idea to fix issue no. 2 (which IMO is easier to accomplish) - and by fix I mean provide a way to define who can execute what - so that we don’t care about issue no. 1 any more. Let’s try to figure out if indeed these are some serious problems that need to be addressed or not. We can discuss implementation details afterwards. Cheers, Radu
Re: [sling:resourceType] protected execution
Hi, On Fri, Oct 5, 2018 at 6:52 AM Carsten Ziegeler wrote: > ...I would like to get briefly back to the use case of this "dangerous > servlet". Why isn't that servlet doing the permission checks which I > think is way safer than relying on additional magic somewhere else > (regardless of what it is)?... That servlet can of course do its own checks, but how? I don't think we have a recommended way of doing that, nor tools that help. The goal here is to define a standard way for how code running in Sling can check permissions, which can be as simple as void checkAllPermissions(ResourceResolver context, String ... permissionName) throws PermissionDeniedException One idea discussed earlier was to create a generic permissions checking service for that. Here I think Radu is taking the angle that such permissions are currently only needed for resource types, servlets and scripts, so this permissions API and impl can stay internal to the servlets resolver module for now. I think that works, provided that's designed in a way that allow us to take it out into a standalone module if needed later. -Bertrand
Re: [sling:resourceType] protected execution
Jason E Bailey wrote> I did not mean to imply that you couldn't browse the tree :):) > > Rather, for me to configure ACL on a script right now I can use composum or > crxde to go to the script and change the ACL on the parent of that script. > My expectation for "the best way" to handle authentication for a servlet > would be to use composum or crxde and go to the resource that the servlet > creates and sets the authentication for that servlet on it's parent the same > way that I would do for a script. But again, aren't we using a service user to read/execute the script? > > IMHO I think the loose end is that the focus is too narrow. One of the things > that came out of the adaptTo is the desire to be able to replace the jcr with > other resourceProviders. The last real step to that goal is an implementation > of a security architecture that replaces what the jcr provides and instead > turns the jcr into just another resourceprovider that also plugs into the > Sling security architecture. Well, this will be a fun discussion :) Adding security on top of something is usually easier to be bypassed than having security built-in. But I would like to get briefly back to the use case of this "dangerous servlet". Why isn't that servlet doing the permission checks which I think is way safer than relying on additional magic somewhere else (regardless of what it is)? Regards Carsten > > -- > Jason > > On Thu, Oct 4, 2018, at 11:43 AM, Carsten Ziegeler wrote: >> I would say, yes you can to both of it :) >> >> ResourceAccessGate has different permissions, one of them is execute. So >> if we base the solution on that, you can still browse the tree. The >> implementation of a RAG can do whatever it wants, so it can read >> permissions from somewhere. >> >> But maybe I'm overlooking something, when it comes to reading/executing >> a script, atm a service user is used for that, not the current user. >> That's to avoid to open up the search paths for everyone to read. >> >> So I think there are more loose ends here. >> >> Regards >> >> Carsten >> >> >> Jason E Bailey wrote >>> I'm beginning to think that there is two different mental models that >>> people who work with Sling take on. One is an OSGi model, where a solution >>> can be achieved via a Service and the creation and configuration of that >>> service(s). The other is a resource centric model where everything must be >>> exposed as a resource, and be configurable by changing properties on a >>> resource. >>> >>> From a resource pov the ResourceAccessGate is difficult and potentially >>> fails because I can't go through the resource tree and see what is and >>> isn't protected on the tree itself, nor can I configure a ResourcAccessGate >>> by defining permissions on a node. >>> >>> -- >>> Jason >>> >>> On Thu, Oct 4, 2018, at 11:15 AM, Carsten Ziegeler wrote: Why is that? I think that's a bold statement. ResourceAccessGate has been developed (afaik) with this use case in mind. Carsten Bertrand Delacretaz wrote > Hi, > > On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: >> ...I am still convinced that this issue could be simply and >> elegantly be solved with a ResourceAccessGate for both servlets and >> scripts in a generic way... > > This would probably work but I think it's not intuitive at all, and as > such error-prone. > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
Hi Radu, Technically, my solution does have all the configuration in a central place. That being the web console where the OSGi service configurations can be viewed, modified, added and deleted by admin. And I don't have to worry about securing read/write/delete access your new proposed security nodes. Regards, Eric On Thu, Oct 4, 2018, 4:45 AM Radu Cotescu wrote: > Hi Eric, > > > On 3 Oct 2018, at 20:50, Eric Norman wrote: > > > > 1. To handle POST requests, each servlet does it's own access checking in > > java code to ensure the right privileges are granted before any > processing > > happens. > > > > 2. To handle GET requests I utilize two generic filters whose > configuration > > is supplied by other multiple "config" OSGi services: > > a) SelectorWhitelistFilter - block access to any unexpected selectors. > A > > SelectorWhitelist configuration OSGi service is registered for each > > resource type to declare which selectors are allowed for each resource > type. > > b) BlockNotAuthorizedFilter - for selectors that get past #1, check > > permissions and block access for users who don't have the required > > privileges. A NotAuthorized OSGi service is registered for each family > of > > scripts to do the appropriate checks. > > I like both ideas, but I’d like to have something generic in Sling where > one can control the whole execution privileges schema from a central place, > which ideally wouldn’t imply any code to be written, just configuration. > > I think I could easily add method + selector combinations into the model I > was proposing. > > Thanks for the hints! > > Regards, > Radu
Re: [sling:resourceType] protected execution
I did not mean to imply that you couldn't browse the tree :) Rather, for me to configure ACL on a script right now I can use composum or crxde to go to the script and change the ACL on the parent of that script. My expectation for "the best way" to handle authentication for a servlet would be to use composum or crxde and go to the resource that the servlet creates and sets the authentication for that servlet on it's parent the same way that I would do for a script. IMHO I think the loose end is that the focus is too narrow. One of the things that came out of the adaptTo is the desire to be able to replace the jcr with other resourceProviders. The last real step to that goal is an implementation of a security architecture that replaces what the jcr provides and instead turns the jcr into just another resourceprovider that also plugs into the Sling security architecture. -- Jason On Thu, Oct 4, 2018, at 11:43 AM, Carsten Ziegeler wrote: > I would say, yes you can to both of it :) > > ResourceAccessGate has different permissions, one of them is execute. So > if we base the solution on that, you can still browse the tree. The > implementation of a RAG can do whatever it wants, so it can read > permissions from somewhere. > > But maybe I'm overlooking something, when it comes to reading/executing > a script, atm a service user is used for that, not the current user. > That's to avoid to open up the search paths for everyone to read. > > So I think there are more loose ends here. > > Regards > > Carsten > > > Jason E Bailey wrote > > I'm beginning to think that there is two different mental models that > > people who work with Sling take on. One is an OSGi model, where a solution > > can be achieved via a Service and the creation and configuration of that > > service(s). The other is a resource centric model where everything must be > > exposed as a resource, and be configurable by changing properties on a > > resource. > > > > From a resource pov the ResourceAccessGate is difficult and potentially > > fails because I can't go through the resource tree and see what is and > > isn't protected on the tree itself, nor can I configure a ResourcAccessGate > > by defining permissions on a node. > > > > -- > > Jason > > > > On Thu, Oct 4, 2018, at 11:15 AM, Carsten Ziegeler wrote: > >> Why is that? I think that's a bold statement. > >> > >> ResourceAccessGate has been developed (afaik) with this use case in mind. > >> > >> Carsten > >> > >> > >> Bertrand Delacretaz wrote > >>> Hi, > >>> > >>> On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: > ...I am still convinced that this issue could be simply and > elegantly be solved with a ResourceAccessGate for both servlets and > scripts in a generic way... > >>> > >>> This would probably work but I think it's not intuitive at all, and as > >>> such error-prone. > >>> > >>> -Bertrand > >>> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [sling:resourceType] protected execution
I would say, yes you can to both of it :) ResourceAccessGate has different permissions, one of them is execute. So if we base the solution on that, you can still browse the tree. The implementation of a RAG can do whatever it wants, so it can read permissions from somewhere. But maybe I'm overlooking something, when it comes to reading/executing a script, atm a service user is used for that, not the current user. That's to avoid to open up the search paths for everyone to read. So I think there are more loose ends here. Regards Carsten Jason E Bailey wrote > I'm beginning to think that there is two different mental models that people > who work with Sling take on. One is an OSGi model, where a solution can be > achieved via a Service and the creation and configuration of that service(s). > The other is a resource centric model where everything must be exposed as a > resource, and be configurable by changing properties on a resource. > > From a resource pov the ResourceAccessGate is difficult and potentially fails > because I can't go through the resource tree and see what is and isn't > protected on the tree itself, nor can I configure a ResourcAccessGate by > defining permissions on a node. > > -- > Jason > > On Thu, Oct 4, 2018, at 11:15 AM, Carsten Ziegeler wrote: >> Why is that? I think that's a bold statement. >> >> ResourceAccessGate has been developed (afaik) with this use case in mind. >> >> Carsten >> >> >> Bertrand Delacretaz wrote >>> Hi, >>> >>> On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: ...I am still convinced that this issue could be simply and elegantly be solved with a ResourceAccessGate for both servlets and scripts in a generic way... >>> >>> This would probably work but I think it's not intuitive at all, and as >>> such error-prone. >>> >>> -Bertrand >>> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
I'm beginning to think that there is two different mental models that people who work with Sling take on. One is an OSGi model, where a solution can be achieved via a Service and the creation and configuration of that service(s). The other is a resource centric model where everything must be exposed as a resource, and be configurable by changing properties on a resource. >From a resource pov the ResourceAccessGate is difficult and potentially fails >because I can't go through the resource tree and see what is and isn't >protected on the tree itself, nor can I configure a ResourcAccessGate by >defining permissions on a node. -- Jason On Thu, Oct 4, 2018, at 11:15 AM, Carsten Ziegeler wrote: > Why is that? I think that's a bold statement. > > ResourceAccessGate has been developed (afaik) with this use case in mind. > > Carsten > > > Bertrand Delacretaz wrote > > Hi, > > > > On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: > >> ...I am still convinced that this issue could be simply and > >> elegantly be solved with a ResourceAccessGate for both servlets and > >> scripts in a generic way... > > > > This would probably work but I think it's not intuitive at all, and as > > such error-prone. > > > > -Bertrand > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [sling:resourceType] protected execution
Why is that? I think that's a bold statement. ResourceAccessGate has been developed (afaik) with this use case in mind. Carsten Bertrand Delacretaz wrote > Hi, > > On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: >> ...I am still convinced that this issue could be simply and >> elegantly be solved with a ResourceAccessGate for both servlets and >> scripts in a generic way... > > This would probably work but I think it's not intuitive at all, and as > such error-prone. > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
Does it work for scripts? How? Carsten Bertrand Delacretaz wrote > On Thu, Oct 4, 2018 at 4:50 PM Jason E Bailey wrote: >> ...a user can create a resource with a rt/danger resourceType but they can't >> execute it unless they have permission to >> execute the rt/danger resource. >> >> We do this for our script under /apps/ where we prevent access to certain >> groups so that even if they create the resource >> that references it, it won't work for them > > That works for scripts, but how about servlets? I think that's where > this proposal makes sense. > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
Hi, On Thu, Oct 4, 2018 at 4:43 PM Julian Sedding wrote: > ...I am still convinced that this issue could be simply and > elegantly be solved with a ResourceAccessGate for both servlets and > scripts in a generic way... This would probably work but I think it's not intuitive at all, and as such error-prone. -Bertrand
Re: [sling:resourceType] protected execution
On Thu, Oct 4, 2018 at 4:50 PM Jason E Bailey wrote: > ...a user can create a resource with a rt/danger resourceType but they can't > execute it unless they have permission to > execute the rt/danger resource. > > We do this for our script under /apps/ where we prevent access to certain > groups so that even if they create the resource > that references it, it won't work for them That works for scripts, but how about servlets? I think that's where this proposal makes sense. -Bertrand
Re: [sling:resourceType] protected execution
> > Any user who can create a Resource with the rt/danger resource type > can execute the DangerousServlet. Same for scripts. > To be clear though, a user can create a resource with a rt/danger resourceType but they can't execute it unless they have permission to execute the rt/danger resource. We do this for our script under /apps/ where we prevent access to certain groups so that even if they create the resource that references it, it won't work for them. - Jason
Re: [sling:resourceType] protected execution
Hi Radu I think your proposed solution is unnecessarily intrusive and complicated. I am still convinced that this issue could be simply and elegantly be solved with a ResourceAccessGate for both servlets and scripts in a generic way. I think you mean well, but I am under the impression that you slightly misunderstand or lack a deep understanding of Sling's resource tree abstraction and how ResourceAccessGates fit in. Let me explain and you be the judge of whether you misunderstood or not ;) Or indeed if my understanding turns out to be incorrect. Note: I didn't check any camel-cased names to be real class-names and thus blurb is meant to be conceptually correct rather than precise in the details. Sling's resource tree is an aggregate view composed of resources contributed by multiple ResourceProviders. - Most commonly, scripts (e.g. jsp, htl) are stored in a JCR repository and are thus contributed by the JcrResourceProvider. - Servlets are hooked into Sling's resource tree by registering a ServletResourceProvider for each Servlet. - Scripts can be pre-compiled and packaged into bundles as resources exposed by a BundleResourceProvider. IIUC the ResourceAccessGate operates on Slings' resource tree, i.e. the aggregate view. Therefore I would expect it to work seamlessly to deny access to servlets and scripts (servlets are actually handled as scripts with extension "servlet" internally AFAIK). Examples: - DefaultPostServlet, registered at "/libs/sling/servlet/default/POST.servlet", meaning [resourceType=sling/servlet/default, method=POST, script-engine=servlet] - SlingJUnitServlet, registered at "/libs/sling/junit/testing/junit.GET.servlet".,meaning [resourceType=sling/junit/testing, method=GET, extension=junit, script-engine=servlet] - the script /apps/sling/info/info.jsp [resourceType=sling/info, script-engine=jsp] So securing /libs/sling/junit would prevent access to the SlingJUnitServlet, just like securing /apps/sling/info would prevent access to the script /apps/sling/info/info.jsp. There is one possible pitfall that I see: I believe the ScriptResolver uses a service user internally. But maybe we could get our hands on the current request's user and fix this if it is indeed a problem. I hope this helps create a clearer image of what I proposed in the previous thread. Regards Julian On Thu, Oct 4, 2018 at 2:06 PM Radu Cotescu wrote: > > Hi Jason, > > > On 3 Oct 2018, at 22:26, Jason E Bailey wrote: > > > > On Wed, Oct 3, 2018, at 7:57 AM, Radu Cotescu wrote: > > > >> Servlets do create Sling resources, but that’s not applicable to scripts > >> deployed in the search paths. > > > > Could you clarify that a bit for me. I'm under the impression that in Sling > > everything is a resource, when does it not create a resource? > > Sure. A servlet registration, like Justin mentioned on the referenced thread > [0], creates a ResourceProvider mapped to a certain path - just check > /system/console/status-jcrresolver and see the reported paths. Search path > scripts, although at runtime generate Servlets (through adaptation), they > will not generate a similar ResourceProvider like proper Servlets do. > > I guess what I wanted to say is that the behaviour regarding what gets > generated for a resource type mapping is not consistent, hence why trying to > work with what we already have would be difficult, since we’d have to secure > the RP entries (which get created dynamically) and the scripts, but these > resources would be all over the place. > > For now my suggestion is to create an isolated content tree where we’d define > different kinds of permissions, where the sling:resourceType execution would > be one of them. I wouldn’t expose any API for it, just make it an > implementation detail of the Sling Engine. If we figure out we want more > types of permissions we either extend the tree or we start creating an API to > manage everything and maybe even delegate permission storage to other systems. > > Cheers, > Radu
Re: [sling:resourceType] protected execution
Hi, On Thu, Oct 4, 2018 at 1:51 PM Carsten Ziegeler wrote: > ...I'm a little bit unclear what this proposal is trying to solve?.. The typical case is a DangerousServlet registered for the rt/danger resource type, which should be restricted to a subset of users. Any user who can create a Resource with the rt/danger resource type can execute the DangerousServlet. Same for scripts. There are workarounds: limit the paths on which the servlet can operate and protect those paths, or check for a configurable permission in the servlet's code as Eric mentions - but having a cleaner mechanism makes sense IMO. -Bertrand
Re: [sling:resourceType] protected execution
Hi Jason, > On 3 Oct 2018, at 22:26, Jason E Bailey wrote: > > On Wed, Oct 3, 2018, at 7:57 AM, Radu Cotescu wrote: > >> Servlets do create Sling resources, but that’s not applicable to scripts >> deployed in the search paths. > > Could you clarify that a bit for me. I'm under the impression that in Sling > everything is a resource, when does it not create a resource? Sure. A servlet registration, like Justin mentioned on the referenced thread [0], creates a ResourceProvider mapped to a certain path - just check /system/console/status-jcrresolver and see the reported paths. Search path scripts, although at runtime generate Servlets (through adaptation), they will not generate a similar ResourceProvider like proper Servlets do. I guess what I wanted to say is that the behaviour regarding what gets generated for a resource type mapping is not consistent, hence why trying to work with what we already have would be difficult, since we’d have to secure the RP entries (which get created dynamically) and the scripts, but these resources would be all over the place. For now my suggestion is to create an isolated content tree where we’d define different kinds of permissions, where the sling:resourceType execution would be one of them. I wouldn’t expose any API for it, just make it an implementation detail of the Sling Engine. If we figure out we want more types of permissions we either extend the tree or we start creating an API to manage everything and maybe even delegate permission storage to other systems. Cheers, Radu
Re: [sling:resourceType] protected execution
I guess it would help if some use cases where listed here. Atm I'm a little bit unclear what this proposal is trying to solve? Regards Carsten Eric Norman wrote > Is it the resource type that needs protection? Or the script/servlet that > is handling a specific method+selector+extension for the resource type? > > I generally prefer to have all my servlets get called regardless of whether > the user has rights to do that action so any invalid requests can be > handled in a consistent manner and I can block passing off the handling to > other unknown handlers. A servlet (or filter) can easily do access checks > in java code at the beginning of the handler and send the appropriate error > response if the user doesn't have the right privileges. And we already > have the OptingServlet interface for servlets which may choose to not > handle all requests for which they would be selected if you want the > handling to fall through. > > For my own projects, I used to do access checking in each "esp" script, but > after migrating to from "esp" to "htl" scripts some refactoring was > required and this is what I came up with: > 1. To handle POST requests, each servlet does it's own access checking in > java code to ensure the right privileges are granted before any processing > happens. > > 2. To handle GET requests I utilize two generic filters whose configuration > is supplied by other multiple "config" OSGi services: > a) SelectorWhitelistFilter - block access to any unexpected selectors. A > SelectorWhitelist configuration OSGi service is registered for each > resource type to declare which selectors are allowed for each resource type. > b) BlockNotAuthorizedFilter - for selectors that get past #1, check > permissions and block access for users who don't have the required > privileges. A NotAuthorized OSGi service is registered for each family of > scripts to do the appropriate checks. > > The code was pretty simple and I could probably share it if anyone is > interested. > > Regards, > -Eric > > On Wed, Oct 3, 2018 at 4:57 AM Radu Cotescu wrote: > >> Hi, >> >> A recent thread [0] presented the idea of adding a more generic mechanism >> to restrict the execution of certain servlets, based on capabilities; >> however, we didn’t reach any consensus. >> >> Several suggestions were presented, based on providing additional >> ResourceProviders or implementing ResourceAccessGates, but we never got >> anywhere and I think that neither of those two approaches are complete. >> >> Servlets do create Sling resources, but that’s not applicable to scripts >> deployed in the search paths. IMO, we’d need one central place where we >> evaluate resource type execution permission and this should happen in the >> org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t >> think we’d need a new external API for now, hence why I’d limit the >> implementation to something very simple: >> >> 1. Create a /system/permissions protected resource (restrict access based >> on ACLs) >> 2. Define permissions that can be added: e.g. >> /system/permissions/sling:resourceType >> 3. Define resource types that need to be protected: e.g. >> /system/permissions/sling:resourceType/org/acme/weather >> 4. Define ACLs that govern who can execute a certain resource type: e.g. >> /system/permissions/sling:resourceType/org/acme/weather/rep:policy where >> we’d whitelist (allow) reading (jcr:read) for certain principals >> 5. In the ServletResolver check the current resource type, find its >> mapping in /system/permissions/sling:resourceType and see if the current >> user can read it (Resource API) >> 5.1. If the user can read it, continue with the regular flow of servlet >> resolution - the user is allowed to execute the current resource type >> 5.2. If not, there are two options: >> 5.2.1. the resource exists (check with a higher privileged user), >> which means that the current user should not be allowed to execute >> whatever’s mapped behind the resource type >> 5.2.2. the resource doesn’t exist, which means that the resource >> type is not protected, so we continue with the normal servlet resolution >> phase >> >> In this way we’d delegate all the checks to the ResourceProviders. The >> persistence mechanism that Sling uses would define what and how can be >> accessed, given that Sling has no other way to enforce Resource access >> control - the ResourceAccessGate API seems incomplete. It’s important to >> note that this implementation would be based though on content structures, >> which have to be stable. As soon as we have to change the structure we >> introduce breaking changes, which will not be easy to handle. >> >> Thoughts? >> >> Thanks, >> Radu >> >> [0] - >> https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [sling:resourceType] protected execution
Hi Eric, > On 3 Oct 2018, at 20:50, Eric Norman wrote: > > 1. To handle POST requests, each servlet does it's own access checking in > java code to ensure the right privileges are granted before any processing > happens. > > 2. To handle GET requests I utilize two generic filters whose configuration > is supplied by other multiple "config" OSGi services: > a) SelectorWhitelistFilter - block access to any unexpected selectors. A > SelectorWhitelist configuration OSGi service is registered for each > resource type to declare which selectors are allowed for each resource type. > b) BlockNotAuthorizedFilter - for selectors that get past #1, check > permissions and block access for users who don't have the required > privileges. A NotAuthorized OSGi service is registered for each family of > scripts to do the appropriate checks. I like both ideas, but I’d like to have something generic in Sling where one can control the whole execution privileges schema from a central place, which ideally wouldn’t imply any code to be written, just configuration. I think I could easily add method + selector combinations into the model I was proposing. Thanks for the hints! Regards, Radu
Re: [sling:resourceType] protected execution
On Wed, Oct 3, 2018, at 7:57 AM, Radu Cotescu wrote: > Servlets do create Sling resources, but that’s not applicable to scripts > deployed in the search paths. Could you clarify that a bit for me. I'm under the impression that in Sling everything is a resource, when does it not create a resource? Thanks -Jason
Re: [sling:resourceType] protected execution
Is it the resource type that needs protection? Or the script/servlet that is handling a specific method+selector+extension for the resource type? I generally prefer to have all my servlets get called regardless of whether the user has rights to do that action so any invalid requests can be handled in a consistent manner and I can block passing off the handling to other unknown handlers. A servlet (or filter) can easily do access checks in java code at the beginning of the handler and send the appropriate error response if the user doesn't have the right privileges. And we already have the OptingServlet interface for servlets which may choose to not handle all requests for which they would be selected if you want the handling to fall through. For my own projects, I used to do access checking in each "esp" script, but after migrating to from "esp" to "htl" scripts some refactoring was required and this is what I came up with: 1. To handle POST requests, each servlet does it's own access checking in java code to ensure the right privileges are granted before any processing happens. 2. To handle GET requests I utilize two generic filters whose configuration is supplied by other multiple "config" OSGi services: a) SelectorWhitelistFilter - block access to any unexpected selectors. A SelectorWhitelist configuration OSGi service is registered for each resource type to declare which selectors are allowed for each resource type. b) BlockNotAuthorizedFilter - for selectors that get past #1, check permissions and block access for users who don't have the required privileges. A NotAuthorized OSGi service is registered for each family of scripts to do the appropriate checks. The code was pretty simple and I could probably share it if anyone is interested. Regards, -Eric On Wed, Oct 3, 2018 at 4:57 AM Radu Cotescu wrote: > Hi, > > A recent thread [0] presented the idea of adding a more generic mechanism > to restrict the execution of certain servlets, based on capabilities; > however, we didn’t reach any consensus. > > Several suggestions were presented, based on providing additional > ResourceProviders or implementing ResourceAccessGates, but we never got > anywhere and I think that neither of those two approaches are complete. > > Servlets do create Sling resources, but that’s not applicable to scripts > deployed in the search paths. IMO, we’d need one central place where we > evaluate resource type execution permission and this should happen in the > org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t > think we’d need a new external API for now, hence why I’d limit the > implementation to something very simple: > > 1. Create a /system/permissions protected resource (restrict access based > on ACLs) > 2. Define permissions that can be added: e.g. > /system/permissions/sling:resourceType > 3. Define resource types that need to be protected: e.g. > /system/permissions/sling:resourceType/org/acme/weather > 4. Define ACLs that govern who can execute a certain resource type: e.g. > /system/permissions/sling:resourceType/org/acme/weather/rep:policy where > we’d whitelist (allow) reading (jcr:read) for certain principals > 5. In the ServletResolver check the current resource type, find its > mapping in /system/permissions/sling:resourceType and see if the current > user can read it (Resource API) > 5.1. If the user can read it, continue with the regular flow of servlet > resolution - the user is allowed to execute the current resource type > 5.2. If not, there are two options: > 5.2.1. the resource exists (check with a higher privileged user), > which means that the current user should not be allowed to execute > whatever’s mapped behind the resource type > 5.2.2. the resource doesn’t exist, which means that the resource > type is not protected, so we continue with the normal servlet resolution > phase > > In this way we’d delegate all the checks to the ResourceProviders. The > persistence mechanism that Sling uses would define what and how can be > accessed, given that Sling has no other way to enforce Resource access > control - the ResourceAccessGate API seems incomplete. It’s important to > note that this implementation would be based though on content structures, > which have to be stable. As soon as we have to change the structure we > introduce breaking changes, which will not be easy to handle. > > Thoughts? > > Thanks, > Radu > > [0] - > https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E
[sling:resourceType] protected execution
Hi, A recent thread [0] presented the idea of adding a more generic mechanism to restrict the execution of certain servlets, based on capabilities; however, we didn’t reach any consensus. Several suggestions were presented, based on providing additional ResourceProviders or implementing ResourceAccessGates, but we never got anywhere and I think that neither of those two approaches are complete. Servlets do create Sling resources, but that’s not applicable to scripts deployed in the search paths. IMO, we’d need one central place where we evaluate resource type execution permission and this should happen in the org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t think we’d need a new external API for now, hence why I’d limit the implementation to something very simple: 1. Create a /system/permissions protected resource (restrict access based on ACLs) 2. Define permissions that can be added: e.g. /system/permissions/sling:resourceType 3. Define resource types that need to be protected: e.g. /system/permissions/sling:resourceType/org/acme/weather 4. Define ACLs that govern who can execute a certain resource type: e.g. /system/permissions/sling:resourceType/org/acme/weather/rep:policy where we’d whitelist (allow) reading (jcr:read) for certain principals 5. In the ServletResolver check the current resource type, find its mapping in /system/permissions/sling:resourceType and see if the current user can read it (Resource API) 5.1. If the user can read it, continue with the regular flow of servlet resolution - the user is allowed to execute the current resource type 5.2. If not, there are two options: 5.2.1. the resource exists (check with a higher privileged user), which means that the current user should not be allowed to execute whatever’s mapped behind the resource type 5.2.2. the resource doesn’t exist, which means that the resource type is not protected, so we continue with the normal servlet resolution phase In this way we’d delegate all the checks to the ResourceProviders. The persistence mechanism that Sling uses would define what and how can be accessed, given that Sling has no other way to enforce Resource access control - the ResourceAccessGate API seems incomplete. It’s important to note that this implementation would be based though on content structures, which have to be stable. As soon as we have to change the structure we introduce breaking changes, which will not be easy to handle. Thoughts? Thanks, Radu [0] - https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E
