You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2011/11/12 04:29:09 UTC
[RT] Improving access control
We support different resource providers, JCR, bundle, file etc. but so
far only JCR implements access control based on the provided user.
This leads to problems when resources are provided for example from a
bundle or the file system as there is either no real ACL check is in
place.
I think we should change that!
First, if a resource provider supports ACL checks like JCR it just
should declare this by using a new interface ACLAwareResourceProvider
(or any better name) which is just a marker interface.
If a resource is provided by provider which does not declare this,
well send the resource through a new service ResourceAccessControler
(or a better name) which either allows or denies the resource. We
could allow here several services which are asked in the order of
their service ranking until one of them provides a definite answer. If
none provides an answer, the resource is served - for compatibility.
With this we should be able to easily hook on access control for such
providers not directly supporting it while staying compatible.
Now, however there is a problem with the whole apprach - if a provider
is an ACLAwareResourceProvider we need to know internally if the
resource exists but the user is not allowed to access it, or if the
resource does not exist. Otherwise we potentially end up with a
resource at /somepath provided by provider A for user U1, and provided
by provider B for user U2 as user U2 is not allowed to access this
resource in provider A.
WDYT?
Regads
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/14 Alexander Klimetschek <ak...@adobe.com>:
> On 13.11.11 22:35, "jsedding@gmail.com" <js...@gmail.com> wrote:
>>ResourceAccessController would be a new concept and interface, which
>>allows different implementations as services. A
>>ResourceAccessController (presumably again) indicates whether access
>>is granted or denied.
>>
>>The variation I propose is to drop the ACLAwareResourceProvider
>>concept and implement a ResourceAccessController for JCR resources
>>instead. The implementation would grant or deny access to a resource
>>based on ACLs in Jackrabbit.
>>...
>>I'm not using the term ACL, as the ResourceAccessController are no
>>declarative lists of access control information. They can be
>>implemented in java, and one possible implementation are ACLs.
>
> Hmm, doesn't this make ACL evaluation possibly much more difficult? It is
> already not always straightforward (although perfectly specified) how
> resource based or principal based ACLs inherit, what an effective ACL is
> made of etc. Allowing yet another mechanism to basically override the JCR
> access control "from the outside" doesn't sound good to me.
>
This whole idea is not to fix/change ACL handling in JCR, it's about
handling this in general in Sling. And I think Julian came up with a
general approach which looks tempting - even if this would mean that
ACL handling can be made more complicated in the JCR case (but that
would be something which a user of Sling would need to implement by
himself).
This general approach would simplify Sling's architecture and
implementation compared to my solution and it would open up for
interesting use cases.
That said, we haven't decided or implemented anything yet :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: [RT] Improving access control
Posted by Mike Müller <mi...@mysign.ch>.
> 2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> > On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> >> This idea is about to provide a general approach for resource
> >> checking
> >>...
> >> Think in terms of our resource abstraction - so far I don't see the
> >> need to define any API to set/change/query these additional checks
> >> within Sling.
> >
> > But these restrictions on resource access will need to be defined
> > somewhere, right?
> > How do you see this?
> >
> I don't care :) We just provide the interface/hook to do that. If
> you're using a repository then maybe the shadow tree is a good
> approach. If you don't have a repo, you need something else.
> In some cases, you might just want to check if the current user is
> admin and allow things, or if the user is authenticated at all. Or you
> want to query your LDAP. Or variations on the theme.
>
> We're providing a framework which should not prevent users from doing
> their stuff - and as we see with Mike's case, there are valid use
> cases.
>
> And even with doing the jcr shadow tree or something like on/off times
> in the repository, with the provided interface you have a good way of
> hooking this into the system :)
+1
It's not about avoiding JCR ACLs, it's more about to make the access
controlling more flexible and independent from the JCR. But the feature
should not prevent the user just to use JCR ACLs.
So the extension is built only as a service interface to "intercept" the
normal flow if needed.
best regards
mike
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> This idea is about to provide a general approach for resource
>> checking
>>...
>> Think in terms of our resource abstraction - so far I don't see the
>> need to define any API to set/change/query these additional checks
>> within Sling.
>
> But these restrictions on resource access will need to be defined
> somewhere, right?
> How do you see this?
>
I don't care :) We just provide the interface/hook to do that. If
you're using a repository then maybe the shadow tree is a good
approach. If you don't have a repo, you need something else.
In some cases, you might just want to check if the current user is
admin and allow things, or if the user is authenticated at all. Or you
want to query your LDAP. Or variations on the theme.
We're providing a framework which should not prevent users from doing
their stuff - and as we see with Mike's case, there are valid use
cases.
And even with doing the jcr shadow tree or something like on/off times
in the repository, with the provided interface you have a good way of
hooking this into the system :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> This idea is about to provide a general approach for resource
> checking
>...
> Think in terms of our resource abstraction - so far I don't see the
> need to define any API to set/change/query these additional checks
> within Sling.
But these restrictions on resource access will need to be defined
somewhere, right?
How do you see this?
-Bertrand
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/23 Vidar Ramdal <vi...@webstep.no>:
> 2011/11/23 Mike Müller <mi...@mysign.ch>:
>> I think the discussion here is missunderstood. It's neither about
>> to redefine existing ACLs nor about reinventing something already
>> existing. It's just about introducing hooks or entrypoint to let
>> developers define some other access controlling rules if needed.
>> Sling will NOT have to deal with permissions or policies, users and so
>> on. That's all up to the developer which want's to use the hooks.
>> So if you're are fine with the ACLs from JCR, you don't have to
>> change anything, if you are not, this would give you the chance
>> to solve your problem (like my example to give access to a
>> resource from 8.00 to 17.00).
>> So
>> It would help not only for special rules like the one above, it would
>> also help to handle access controlling on resources which are provided
>> from another resource provider than JCR, like the file system provider,
>> where no access controlling can be attached today.
>
> Being picky here: We could provide access control by extending the
> file system provider to support it. And your example of
> time-restricted access could be implemented in Jackrabbit's existing
> AccessManager.
Yepp, right - looking at Felix recent proposal which basically does
this, this is an option. And I agree that we should consider this
option; it has advantages but on the other hand requires that a
resource provider implements all potential use cases. If we take
Mike's example, you definitely don't want to implement those checks in
each and every provider.
The use case I had in my is the file system provider. In order to have
checks working with a file system you would need to have the same user
for the server than you have for the webapp - which is something you
definitely don't want. So you need a different check here which should
be a generic solution as the real check really depends on your
application. That's where my suggestion is coming from. And I could
imagine similar use cases for other providers. One solution would be
that some providers define their own service interface where you could
hook into.
Use cases like Mike's could be solved with a ResourceDecorator - at
least for reading, delete and update. As we don't have crud yet, we
have to see how this can be solved there.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Vidar Ramdal <vi...@webstep.no>.
2011/11/23 Mike Müller <mi...@mysign.ch>:
> I think the discussion here is missunderstood. It's neither about
> to redefine existing ACLs nor about reinventing something already
> existing. It's just about introducing hooks or entrypoint to let
> developers define some other access controlling rules if needed.
> Sling will NOT have to deal with permissions or policies, users and so
> on. That's all up to the developer which want's to use the hooks.
> So if you're are fine with the ACLs from JCR, you don't have to
> change anything, if you are not, this would give you the chance
> to solve your problem (like my example to give access to a
> resource from 8.00 to 17.00).
> So
> It would help not only for special rules like the one above, it would
> also help to handle access controlling on resources which are provided
> from another resource provider than JCR, like the file system provider,
> where no access controlling can be attached today.
Being picky here: We could provide access control by extending the
file system provider to support it. And your example of
time-restricted access could be implemented in Jackrabbit's existing
AccessManager.
I'm worried we're introducing a layer of resource filtering that will
be hard to enforce across all scenarios, without breaking useability.
I've been thinking more about the search issue. Jackrabbit's Lucene
will report, say 200 results for a query. But Lucene does only know of
Jackrabbit's access rules, not the Sling ones. So out of those 200
results, the user may only have access to 100 of them, or perhaps none
at all. How are we going to report the number of search results to the
end user, without iterating all search results while filtering them
through Sling access control?
The same, I guess, will affect for search features of other resource providers.
OK, maybe the search result size problem is a small one, but I suspect
there are other such cases (that I haven't been able to think about
yet).
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 23, 2011 at 9:27 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 2011/11/23 Mike Müller <mi...@mysign.ch>:
>> I think the discussion here is missunderstood. It's neither about
>> to redefine existing ACLs nor about reinventing something already
>> existing...
Well, this thread's subject says "improving access control" ;-)
> Exactly, thanks Mike :)
Then, let's make sure we don't call this "access control".
I purposely used "ResourceAccessGate" as my example interface name
earlier in this thread - such a name probably helps avoid confusion.
-Bertrand
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/23 Mike Müller <mi...@mysign.ch>:
> I think the discussion here is missunderstood. It's neither about
> to redefine existing ACLs nor about reinventing something already
> existing. It's just about introducing hooks or entrypoint to let
> developers define some other access controlling rules if needed.
> Sling will NOT have to deal with permissions or policies, users and so
> on. That's all up to the developer which want's to use the hooks.
> So if you're are fine with the ACLs from JCR, you don't have to
> change anything, if you are not, this would give you the chance
> to solve your problem (like my example to give access to a
> resource from 8.00 to 17.00).
> So
> It would help not only for special rules like the one above, it would
> also help to handle access controlling on resources which are provided
> from another resource provider than JCR, like the file system provider,
> where no access controlling can be attached today.
> And again: If someone is fine just with the JCR resource provider and
> the ACLs, nothing will be more complicated after the introduction of
> the hook than before.
>
Exactly, thanks Mike :)
And keep in mind that the intend of Sling is to provide a framework to
create a resource oriented architecture. This is not tied to jcr. We
already have other providers (file and bundle) and in the near future
we will have additional providers for other data storages.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: [RT] Improving access control
Posted by Mike Müller <mi...@mysign.ch>.
I think the discussion here is missunderstood. It's neither about
to redefine existing ACLs nor about reinventing something already
existing. It's just about introducing hooks or entrypoint to let
developers define some other access controlling rules if needed.
Sling will NOT have to deal with permissions or policies, users and so
on. That's all up to the developer which want's to use the hooks.
So if you're are fine with the ACLs from JCR, you don't have to
change anything, if you are not, this would give you the chance
to solve your problem (like my example to give access to a
resource from 8.00 to 17.00).
So
It would help not only for special rules like the one above, it would
also help to handle access controlling on resources which are provided
from another resource provider than JCR, like the file system provider,
where no access controlling can be attached today.
And again: If someone is fine just with the JCR resource provider and
the ACLs, nothing will be more complicated after the introduction of
the hook than before.
best regards
mike
> -----Original Message-----
> From: Tobias Bocanegra [mailto:tripod@adobe.com]
> Sent: Wednesday, November 23, 2011 1:04 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] Improving access control
>
> Hi,
> I fear the same, that sling tries to re-define and re-implement the
> whole JCR API stack (it already does for the most part :-(. Initially
> sling was a framework for building web application on top a JCR
> repository. But now it's a framework that happens to integrate nicely
> on JCR. I think the divergence to JCR started when the resource API
> was introduced. Although I like the idea and the elegance of the
> 'everything is a resource' approach, it in facts duplicates the JCR
> API.
>
> Keep in mind that when you define any sort of Access Control API for
> sling, you eventually need to think about ACLs, Permissions, Policies,
> Privileges, Users, Principals, etc... All this is already specified by
> JCR or at least available in Jackrabbit. And as alex said: it only
> shields you on the resource provider level - but not on the JCR level.
>
> btw: I'm not sure how far the support for custom policies in
> jackrabbit is, but the basics are there. So you can (and should)
> implement your 9am-5pm policy definitely on the repository level.
>
> regards, toby
Re: [RT] Improving access control
Posted by Tobias Bocanegra <tr...@adobe.com>.
Hi,
I fear the same, that sling tries to re-define and re-implement the
whole JCR API stack (it already does for the most part :-(. Initially
sling was a framework for building web application on top a JCR
repository. But now it's a framework that happens to integrate nicely
on JCR. I think the divergence to JCR started when the resource API
was introduced. Although I like the idea and the elegance of the
'everything is a resource' approach, it in facts duplicates the JCR
API.
Keep in mind that when you define any sort of Access Control API for
sling, you eventually need to think about ACLs, Permissions, Policies,
Privileges, Users, Principals, etc... All this is already specified by
JCR or at least available in Jackrabbit. And as alex said: it only
shields you on the resource provider level - but not on the JCR level.
btw: I'm not sure how far the support for custom policies in
jackrabbit is, but the basics are there. So you can (and should)
implement your 9am-5pm policy definitely on the repository level.
regards, toby
Re: [RT] Improving access control
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
In any case, setting the scr property to specify the access control
service/class still holds as it allows us to set an initial value using scr
annotations and also we can reuse or reconfigure access control provider
for each resource provider.
Just an idea instead of making the resource provider itself implement the
access control logic.
Sarwar
On Nov 22, 2011 6:46 PM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
> On Tue, Nov 22, 2011 at 6:37 PM, Sarwar Bhuiyan
> <sa...@gmail.com> wrote:
> > ...Bertrand asked what user interface we could use to configure an access
> > control provider...
>
> Sorry, my question was badly phrased: what I meant is that people
> already need to have a UI to configure JCR access control - if this
> new feature requires a different UI it would be a Bad Thing.
>
> And as Carsten mentioned this UI question was not really relevant
> anyway, as this thread is only about providing a low-level mechanism
> to block access to certain resources.
>
> -Bertrand
>
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 22, 2011 at 6:37 PM, Sarwar Bhuiyan
<sa...@gmail.com> wrote:
> ...Bertrand asked what user interface we could use to configure an access
> control provider...
Sorry, my question was badly phrased: what I meant is that people
already need to have a UI to configure JCR access control - if this
new feature requires a different UI it would be a Bad Thing.
And as Carsten mentioned this UI question was not really relevant
anyway, as this thread is only about providing a low-level mechanism
to block access to certain resources.
-Bertrand
Re: [RT] Improving access control
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
Hi all,
Bertrand asked what user interface we could use to configure an access
control provider. We could do some wiring based on an osgi property, if it
exists, using an scr annotation on the resource provider to specify the
service which implements the access control gate (if one is not provided,
use the JCR acl). The SlingMainServlet would check for this and call the
appropriate method (e.g. acceptResource or whatever).
This way, the access control provider can be reused by different resource
providers and we can change it in the OSGi console if required. The actual
implementation can take care of whether to accept read, write, modify, etc.
WDYT?
Sarwar
On Tue, Nov 22, 2011 at 4:11 PM, Carsten Ziegeler <cz...@apache.org>wrote:
> 2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> > On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >> 2011/11/22 Vidar Ramdal <vi...@webstep.no>:
> >>>... I'm coming late to this party, but having read the thread I'm not
> sure
> >>> if the proposal is about a) specifying access control APIs to be
> >>> implemented by resource providers, or b) implement access control
> >>> logic independently from (on top of) resource providers....
> >
> >> ...the idea is about b) - I agree that thinks like search might get a
> >> little bit...well...interesting :) Though if you use the Sling search,
> >> you get resources and they will go through the same check mechanism....
> >
> > Can this be done with a service interface like this, or is there more to
> it?
> >
> > public interface ResourceAccessGate {
> > /** @return false if access to the supplied Resource is denied for
> > supplied request */
> > boolean acceptResource(SlingHttpServletRequest request, Resource
> resource);
> > }
>
> Something similar - though we won't pass a request object into the
> check just the resource (resources can be get without a request) and
> we need to think about how to handle create.
>
> Now, as indicated this is an RT :) I think we won't implement this in
> the next days (patches welcome of course), but as soon as we split the
> resource resolver from the jcr provider, things like these get even
> more interesting (and get easier to implement hopefully)
>
> Regards
> Carsten
>
> >
> > If that's what you mean, I'd be ok as long as we clearly indicate that
> > this is just an additional application-level access gate, not to be
> > confused with ACLs which are handled at the repository level.
> >
> > Just something like the ResourceDecorator that we already have (and
> > both will be called in the same places probably).
> >
> > -Bertrand
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [RT] Improving access control
Posted by Alexander Klimetschek <ak...@adobe.com>.
But again the question (as asked by me and Vidar): why does Sling need
that?
What is wrong with a resource provider simply not returning resources
where the user has no access, as it is already the case with the JCR
provider?
Cheers,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> 2011/11/22 Vidar Ramdal <vi...@webstep.no>:
>>>... I'm coming late to this party, but having read the thread I'm not sure
>>> if the proposal is about a) specifying access control APIs to be
>>> implemented by resource providers, or b) implement access control
>>> logic independently from (on top of) resource providers....
>
>> ...the idea is about b) - I agree that thinks like search might get a
>> little bit...well...interesting :) Though if you use the Sling search,
>> you get resources and they will go through the same check mechanism....
>
> Can this be done with a service interface like this, or is there more to it?
>
> public interface ResourceAccessGate {
> /** @return false if access to the supplied Resource is denied for
> supplied request */
> boolean acceptResource(SlingHttpServletRequest request, Resource resource);
> }
Something similar - though we won't pass a request object into the
check just the resource (resources can be get without a request) and
we need to think about how to handle create.
Now, as indicated this is an RT :) I think we won't implement this in
the next days (patches welcome of course), but as soon as we split the
resource resolver from the jcr provider, things like these get even
more interesting (and get easier to implement hopefully)
Regards
Carsten
>
> If that's what you mean, I'd be ok as long as we clearly indicate that
> this is just an additional application-level access gate, not to be
> confused with ACLs which are handled at the repository level.
>
> Just something like the ResourceDecorator that we already have (and
> both will be called in the same places probably).
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> 2011/11/22 Vidar Ramdal <vi...@webstep.no>:
>>... I'm coming late to this party, but having read the thread I'm not sure
>> if the proposal is about a) specifying access control APIs to be
>> implemented by resource providers, or b) implement access control
>> logic independently from (on top of) resource providers....
> ...the idea is about b) - I agree that thinks like search might get a
> little bit...well...interesting :) Though if you use the Sling search,
> you get resources and they will go through the same check mechanism....
Can this be done with a service interface like this, or is there more to it?
public interface ResourceAccessGate {
/** @return false if access to the supplied Resource is denied for
supplied request */
boolean acceptResource(SlingHttpServletRequest request, Resource resource);
}
If that's what you mean, I'd be ok as long as we clearly indicate that
this is just an additional application-level access gate, not to be
confused with ACLs which are handled at the repository level.
Just something like the ResourceDecorator that we already have (and
both will be called in the same places probably).
-Bertrand
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/22 Vidar Ramdal <vi...@webstep.no>:
> 2011/11/22 Carsten Ziegeler <cz...@apache.org>:
>> This idea is about to provide a general approach for resource
>> checking. Noone prevents you from doing a virtual tree in the jcr
>> repository to check access of resources provided by other providers.
>> But that's an implementation detail which I don't want to require
>> upfront!
>
> I'm coming late to this party, but having read the thread I'm not sure
> if the proposal is about a) specifying access control APIs to be
> implemented by resource providers, or b) implement access control
> logic independently from (on top of) resource providers.
> Can someone clarify?
>
> With b), it would be easy to re-use access control logic across
> resource providers (like the 9:00-17:00 rule), but I suspect it will
> introduce other problems, such as with Jackrabbit's Lucene search
> results - you don't want to return a search result that the user don't
> have access to.
>
> With a), we simply delegate all access control to resource providers
> (like JCR), which will pretend a resource does not exist if the user
> has no access to it. But then, what will be the point of having Sling
> APIs for access control? In other words, why does Sling need to know
> that a resource exists, when it is unaccessible for the user?
>
Hi,
the idea is about b) - I agree that thinks like search might get a
little bit...well...interesting :) Though if you use the Sling search,
you get resources and they will go through the same check mechanism.
Sure, we could go with a) but this would require to forsee such checks
in each and every resource provider and accordingly configure it for
each provider. This is something I wanted to avoid. Use cases like
Mike's sound to fit perfectly into b).
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Vidar Ramdal <vi...@webstep.no>.
2011/11/22 Carsten Ziegeler <cz...@apache.org>:
> This idea is about to provide a general approach for resource
> checking. Noone prevents you from doing a virtual tree in the jcr
> repository to check access of resources provided by other providers.
> But that's an implementation detail which I don't want to require
> upfront!
I'm coming late to this party, but having read the thread I'm not sure
if the proposal is about a) specifying access control APIs to be
implemented by resource providers, or b) implement access control
logic independently from (on top of) resource providers.
Can someone clarify?
With b), it would be easy to re-use access control logic across
resource providers (like the 9:00-17:00 rule), but I suspect it will
introduce other problems, such as with Jackrabbit's Lucene search
results - you don't want to return a search result that the user don't
have access to.
With a), we simply delegate all access control to resource providers
(like JCR), which will pretend a resource does not exist if the user
has no access to it. But then, what will be the point of having Sling
APIs for access control? In other words, why does Sling need to know
that a resource exists, when it is unaccessible for the user?
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: [RT] Improving access control
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 22.11.11 14:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
>This idea is about to provide a general approach for resource
>checking. Noone prevents you from doing a virtual tree in the jcr
>repository to check access of resources provided by other providers.
>But that's an implementation detail which I don't want to require
>upfront!
I just expect that if Sling provides some simple ACL interfaces, people
will start to implement them (w/o ever looking into what JCR ACLs they can
have or implement) and only later detect & complain that it only works
when you do everything in Sling's resource API.
BTW: Where does Sling need resource checking? If something is not
accessible = readable, it should simply not be returned from the resource
provider (as JCR does).
Cheers,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
This idea is about to provide a general approach for resource
checking. Noone prevents you from doing a virtual tree in the jcr
repository to check access of resources provided by other providers.
But that's an implementation detail which I don't want to require
upfront!
Think in terms of our resource abstraction - so far I don't see the
need to define any API to set/change/query these additional checks
within Sling.
Regards
Carsten
2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
> <ak...@adobe.com> wrote:
>> ...Personally I think it is much better to put such additional ACL
>> implementations into the JCR (e.g. a custom Jackrabbit access control
>> provider). The problem is that anytime your code is using JCR (such as for
>> complex operations not possible through the simple resource API) your
>> sling-based access control won't be used at all....
>
> Right...adding an ACL layer that's not based on JCR might generate a
> lot of confusion IMO.
>
> And where are we going to implement user/RESTful interfaces for
> defining such ACLs? New additional APIs and UIs?
>
> To keep things simple I'd suggest using a "shadow resource tree" in
> JCR if we need to define access control for ResourceResolvers which
> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
> repository node define ACL for resource /foo provided by provider
> com.example.bar, for example.
>
> That doesn't solve Mike's time-based ACLs, but I'd handle those
> separately at the application level (or in a Filter) anyway. Having
> ACLs that depend on something else than the current request's
> credentials might break too many existing semantics (caching etc).
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 22, 2011 at 2:43 PM, Vidar Ramdal <vi...@webstep.no> wrote:
> 2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
>> ...To keep things simple I'd suggest using a "shadow resource tree" in
>> JCR if we need to define access control for ResourceResolvers which
>> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
>> repository node define ACL for resource /foo provided by provider
>> com.example.bar, for example.
>
> Hmm, so you are thinking about delegating access control for all kind
> of resources to JCR? Wouldn't that just duplicate resource trees from
> (all) other resource providers into JCR, just for the sake of access
> control?...
The shadow tree could use wildcards, if we want to go that way.
-Bertrand
Re: [RT] Improving access control
Posted by Vidar Ramdal <vi...@webstep.no>.
2011/11/22 Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
> <ak...@adobe.com> wrote:
>> ...Personally I think it is much better to put such additional ACL
>> implementations into the JCR (e.g. a custom Jackrabbit access control
>> provider). The problem is that anytime your code is using JCR (such as for
>> complex operations not possible through the simple resource API) your
>> sling-based access control won't be used at all....
>
> Right...adding an ACL layer that's not based on JCR might generate a
> lot of confusion IMO.
> [...]
> To keep things simple I'd suggest using a "shadow resource tree" in
> JCR if we need to define access control for ResourceResolvers which
> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
> repository node define ACL for resource /foo provided by provider
> com.example.bar, for example.
Hmm, so you are thinking about delegating access control for all kind
of resources to JCR? Wouldn't that just duplicate resource trees from
(all) other resource providers into JCR, just for the sake of access
control?
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> ...Personally I think it is much better to put such additional ACL
> implementations into the JCR (e.g. a custom Jackrabbit access control
> provider). The problem is that anytime your code is using JCR (such as for
> complex operations not possible through the simple resource API) your
> sling-based access control won't be used at all....
Right...adding an ACL layer that's not based on JCR might generate a
lot of confusion IMO.
And where are we going to implement user/RESTful interfaces for
defining such ACLs? New additional APIs and UIs?
To keep things simple I'd suggest using a "shadow resource tree" in
JCR if we need to define access control for ResourceResolvers which
are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
repository node define ACL for resource /foo provided by provider
com.example.bar, for example.
That doesn't solve Mike's time-based ACLs, but I'd handle those
separately at the application level (or in a Filter) anyway. Having
ACLs that depend on something else than the current request's
credentials might break too many existing semantics (caching etc).
-Bertrand
RE: [RT] Improving access control
Posted by Mike Müller <mi...@mysign.ch>.
> I share the performance concern if a jcr node has to be checked twice
> as this would double the repository access per request.
>
> In general I think we can go with this (for reading):
> 1. ResourceProvider delivers resource and maybe does already the ACL
> check (like in the JCR case)
> 2. ResourceAccessController do additional checks
>
> This is a general approach, avoids duplicate checks and ensures that
> it's not possible to circumvent JCR ACLs.
+1
Step 2) can be skipped, if no resource is returned.
And in addition this gives us the possibility to pass the found resource to
the ResourceAccessController. That enables a specific ResourceAccessController
to make the decision to allow or deny access to this ressource dependent
on the data of the resource and not only the path of the resource.
best regards
mike
>
> As mentioned, the only potential drawback is that for the same path
> different users might end up with different resources. But I think we
> can live with that.
>
> Regards
> Carsten
>
> 2011/11/22 Mike Müller <mi...@mysign.ch>:
> > Okay, I might be a little bit late in the discussion...
> > We're at MySign thought about such a access control layer in Sling a few
> > months ago. Mainly because we do have different resource providers
> > without the possibility of ACLs and also because some access rules
> > can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
> > We do have such an access layer in our legacy framework and there
> > we also have the possibility to define the access rules declarative (like
> > ACLs) but also by somtehing like the proposed ResourceAccessController
> > services.
> >
> > I do share Justins fear, that we get poor performance if we do have to
> > call the JCR provider twice to once get to know if the user has access and
> > once to get the resource. But maybe the JCR resource provider can cache
> > the resource from the first call and the performance ist fine.
> > I think we should not design a general architecture for access controlling
> > an make the JCR a special case. I would prefer a "clean" design with only
> > one service interface for access controlling (without exceptions).
> > The approach where the ResourceProvider implements it's own access
> > control mechanism avoids the possibility for a special ResourceAccessController
> > to overwrite some access roles (like the example above with access
> > between 8.00 and 17.00). Plus, it would be less understandable than the
> > clean approach with just one entry point where access controlling is
> > taking place.
> >
> > What I missed in the discussion so far is, that the proposed mechanisms
> > are only usable for read. I think a general access controller mechanism in
> > Sling should provide access controlling for read, write, modify and delete.
> > With such an architecture it would be much easier to control security aspects
> > of the application.
> >
> > best regards
> > mike
> >
> >
> >> -----Original Message-----
> >> From: justinedelson@gmail.com [mailto:justinedelson@gmail.com] On Behalf Of
> Justin
> >> Edelson
> >> Sent: Tuesday, November 15, 2011 5:24 AM
> >> To: dev@sling.apache.org
> >> Subject: Re: [RT] Improving access control
> >>
> >> Thanks for the clarification Julian. This makes more sense. I have two
> >> concerns with the variant you're describing:
> >>
> >> 1) It does not provide a way for ResourceProvider implementers to
> >> provide their own access control mechanism, which is one thing I
> >> really liked in Carsten's original proposal.
> >> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
> >> poor performance because the access control rules in the repository
> >> will be evaluated twice.
> >>
> >> Justin
> >>
> >> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding <js...@gmail.com> wrote:
> >> > Hi Justin
> >> >
> >> > Carsten's original proposal introduced two ways to handle access
> >> > control: ACLAwareResourceProvider and ResourceAccessController.
> >> >
> >> > The ACLAwareResourceProvider would act just like JCR Resources are
> >> > currently handled, i.e. with access control already enforced by the
> >> > underlying storage layer. The interface would merely indicate that
> >> > this ResourceProvider takes care of access control by itself (and
> >> > should presumably bypass any ResourceAccessController services).
> >> >
> >> > ResourceAccessController would be a new concept and interface, which
> >> > allows different implementations as services. A
> >> > ResourceAccessController (presumably again) indicates whether access
> >> > is granted or denied.
> >> >
> >> > The variation I propose is to drop the ACLAwareResourceProvider
> >> > concept and implement a ResourceAccessController for JCR resources
> >> > instead. The implementation would grant or deny access to a resource
> >> > based on ACLs in Jackrabbit.
> >> >
> >> > So a request for /foo would hit the SlingMainServlet, then the
> >> > Authenticator. Let's assume we now have a known user, we ask any
> >> > ResourceAccessController services if the user is granted access. If
> >> > access is denied, an appropriate response is sent (e.g. 403). If
> >> > access is granted, the ResourceProviders will be asked for the
> >> > resource. If the resource is unavailable, a 404 response can be sent,
> >> > otherwise Sling renders the resource.
> >> >
> >> > I'm not using the term ACL, as the ResourceAccessController are no
> >> > declarative lists of access control information. They can be
> >> > implemented in java, and one possible implementation are ACLs.
> >> >
> >> > Does this clarify my previous comment?
> >> >
> >> > Regards
> >> > Julian
> >> >
> >> >
> >> >
> >> > On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
> >> > <ju...@justinedelson.com> wrote:
> >> >> Hi Julian,
> >> >> I don't think I understand what you are suggesting here. Can you
> >> >> elaborate on what the code path would be in the case, for example, of
> >> >> a Bundle Resource Provider? If a bundle provides resources under, say,
> >> >> /mybundle, where would the ACL live and who would be responsible for
> >> >> evaluating it?
> >> >>
> >> >> I feel like I'm missing something obvious, so please bear with me :)
> >> >>
> >> >> Thanks,
> >> >> Justin
> >> >>
> >> >> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com>
> wrote:
> >> >>> Hi Carsten
> >> >>>
> >> >>> Interesting idea. Having access control handled by services allows
> >> >>> implementing arbitrary access control logic, which I would welcome. In
> >> >>> my experience, it's often difficult to express access control logic in
> >> >>> a declarative manner.
> >> >>>
> >> >>> I think we could further simplify the approach you describe. Leave the
> >> >>> ResourceProvider interface as it is and don't introduce an
> >> >>> ACLAwareResourceProvider interface. Instead have the JCR
> >> >>> ResourceProvider also implement ResourceAccessController. This
> >> >>> simplifies the design, while allowing to expose the same logic.
> >> >>> Additionally, it adds the possibility to layer additional access
> >> >>> control on top of Jackrabbit ACLs, thus allowing to combine the best
> >> >>> of both worlds (access control logic implemented in java +
> >> >>> Jackrabbit's declarative ACLs).
> >> >>>
> >> >>> Thoughts?
> >> >>>
> >> >>> Regards
> >> >>> Julian
> >> >>>
> >> >>>
> >> >>> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org>
> >> wrote:
> >> >>>> We support different resource providers, JCR, bundle, file etc. but so
> >> >>>> far only JCR implements access control based on the provided user.
> >> >>>> This leads to problems when resources are provided for example from a
> >> >>>> bundle or the file system as there is either no real ACL check is in
> >> >>>> place.
> >> >>>> I think we should change that!
> >> >>>>
> >> >>>> First, if a resource provider supports ACL checks like JCR it just
> >> >>>> should declare this by using a new interface ACLAwareResourceProvider
> >> >>>> (or any better name) which is just a marker interface.
> >> >>>> If a resource is provided by provider which does not declare this,
> >> >>>> well send the resource through a new service ResourceAccessControler
> >> >>>> (or a better name) which either allows or denies the resource. We
> >> >>>> could allow here several services which are asked in the order of
> >> >>>> their service ranking until one of them provides a definite answer. If
> >> >>>> none provides an answer, the resource is served - for compatibility.
> >> >>>>
> >> >>>> With this we should be able to easily hook on access control for such
> >> >>>> providers not directly supporting it while staying compatible.
> >> >>>>
> >> >>>> Now, however there is a problem with the whole apprach - if a provider
> >> >>>> is an ACLAwareResourceProvider we need to know internally if the
> >> >>>> resource exists but the user is not allowed to access it, or if the
> >> >>>> resource does not exist. Otherwise we potentially end up with a
> >> >>>> resource at /somepath provided by provider A for user U1, and provided
> >> >>>> by provider B for user U2 as user U2 is not allowed to access this
> >> >>>> resource in provider A.
> >> >>>>
> >> >>>> WDYT?
> >> >>>>
> >> >>>> Regads
> >> >>>> Carsten
> >> >>>> --
> >> >>>> Carsten Ziegeler
> >> >>>> cziegeler@apache.org
> >> >>>>
> >> >>>
> >> >>
> >> >
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Mike,
thanks for your valuable input!
Yes, though we didn't talk about it, these checks should not only
apply for reading but in general for all operations.
I share the performance concern if a jcr node has to be checked twice
as this would double the repository access per request.
In general I think we can go with this (for reading):
1. ResourceProvider delivers resource and maybe does already the ACL
check (like in the JCR case)
2. ResourceAccessController do additional checks
This is a general approach, avoids duplicate checks and ensures that
it's not possible to circumvent JCR ACLs.
As mentioned, the only potential drawback is that for the same path
different users might end up with different resources. But I think we
can live with that.
Regards
Carsten
2011/11/22 Mike Müller <mi...@mysign.ch>:
> Okay, I might be a little bit late in the discussion...
> We're at MySign thought about such a access control layer in Sling a few
> months ago. Mainly because we do have different resource providers
> without the possibility of ACLs and also because some access rules
> can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
> We do have such an access layer in our legacy framework and there
> we also have the possibility to define the access rules declarative (like
> ACLs) but also by somtehing like the proposed ResourceAccessController
> services.
>
> I do share Justins fear, that we get poor performance if we do have to
> call the JCR provider twice to once get to know if the user has access and
> once to get the resource. But maybe the JCR resource provider can cache
> the resource from the first call and the performance ist fine.
> I think we should not design a general architecture for access controlling
> an make the JCR a special case. I would prefer a "clean" design with only
> one service interface for access controlling (without exceptions).
> The approach where the ResourceProvider implements it's own access
> control mechanism avoids the possibility for a special ResourceAccessController
> to overwrite some access roles (like the example above with access
> between 8.00 and 17.00). Plus, it would be less understandable than the
> clean approach with just one entry point where access controlling is
> taking place.
>
> What I missed in the discussion so far is, that the proposed mechanisms
> are only usable for read. I think a general access controller mechanism in
> Sling should provide access controlling for read, write, modify and delete.
> With such an architecture it would be much easier to control security aspects
> of the application.
>
> best regards
> mike
>
>
>> -----Original Message-----
>> From: justinedelson@gmail.com [mailto:justinedelson@gmail.com] On Behalf Of Justin
>> Edelson
>> Sent: Tuesday, November 15, 2011 5:24 AM
>> To: dev@sling.apache.org
>> Subject: Re: [RT] Improving access control
>>
>> Thanks for the clarification Julian. This makes more sense. I have two
>> concerns with the variant you're describing:
>>
>> 1) It does not provide a way for ResourceProvider implementers to
>> provide their own access control mechanism, which is one thing I
>> really liked in Carsten's original proposal.
>> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
>> poor performance because the access control rules in the repository
>> will be evaluated twice.
>>
>> Justin
>>
>> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding <js...@gmail.com> wrote:
>> > Hi Justin
>> >
>> > Carsten's original proposal introduced two ways to handle access
>> > control: ACLAwareResourceProvider and ResourceAccessController.
>> >
>> > The ACLAwareResourceProvider would act just like JCR Resources are
>> > currently handled, i.e. with access control already enforced by the
>> > underlying storage layer. The interface would merely indicate that
>> > this ResourceProvider takes care of access control by itself (and
>> > should presumably bypass any ResourceAccessController services).
>> >
>> > ResourceAccessController would be a new concept and interface, which
>> > allows different implementations as services. A
>> > ResourceAccessController (presumably again) indicates whether access
>> > is granted or denied.
>> >
>> > The variation I propose is to drop the ACLAwareResourceProvider
>> > concept and implement a ResourceAccessController for JCR resources
>> > instead. The implementation would grant or deny access to a resource
>> > based on ACLs in Jackrabbit.
>> >
>> > So a request for /foo would hit the SlingMainServlet, then the
>> > Authenticator. Let's assume we now have a known user, we ask any
>> > ResourceAccessController services if the user is granted access. If
>> > access is denied, an appropriate response is sent (e.g. 403). If
>> > access is granted, the ResourceProviders will be asked for the
>> > resource. If the resource is unavailable, a 404 response can be sent,
>> > otherwise Sling renders the resource.
>> >
>> > I'm not using the term ACL, as the ResourceAccessController are no
>> > declarative lists of access control information. They can be
>> > implemented in java, and one possible implementation are ACLs.
>> >
>> > Does this clarify my previous comment?
>> >
>> > Regards
>> > Julian
>> >
>> >
>> >
>> > On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
>> > <ju...@justinedelson.com> wrote:
>> >> Hi Julian,
>> >> I don't think I understand what you are suggesting here. Can you
>> >> elaborate on what the code path would be in the case, for example, of
>> >> a Bundle Resource Provider? If a bundle provides resources under, say,
>> >> /mybundle, where would the ACL live and who would be responsible for
>> >> evaluating it?
>> >>
>> >> I feel like I'm missing something obvious, so please bear with me :)
>> >>
>> >> Thanks,
>> >> Justin
>> >>
>> >> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com> wrote:
>> >>> Hi Carsten
>> >>>
>> >>> Interesting idea. Having access control handled by services allows
>> >>> implementing arbitrary access control logic, which I would welcome. In
>> >>> my experience, it's often difficult to express access control logic in
>> >>> a declarative manner.
>> >>>
>> >>> I think we could further simplify the approach you describe. Leave the
>> >>> ResourceProvider interface as it is and don't introduce an
>> >>> ACLAwareResourceProvider interface. Instead have the JCR
>> >>> ResourceProvider also implement ResourceAccessController. This
>> >>> simplifies the design, while allowing to expose the same logic.
>> >>> Additionally, it adds the possibility to layer additional access
>> >>> control on top of Jackrabbit ACLs, thus allowing to combine the best
>> >>> of both worlds (access control logic implemented in java +
>> >>> Jackrabbit's declarative ACLs).
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Regards
>> >>> Julian
>> >>>
>> >>>
>> >>> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>> >>>> We support different resource providers, JCR, bundle, file etc. but so
>> >>>> far only JCR implements access control based on the provided user.
>> >>>> This leads to problems when resources are provided for example from a
>> >>>> bundle or the file system as there is either no real ACL check is in
>> >>>> place.
>> >>>> I think we should change that!
>> >>>>
>> >>>> First, if a resource provider supports ACL checks like JCR it just
>> >>>> should declare this by using a new interface ACLAwareResourceProvider
>> >>>> (or any better name) which is just a marker interface.
>> >>>> If a resource is provided by provider which does not declare this,
>> >>>> well send the resource through a new service ResourceAccessControler
>> >>>> (or a better name) which either allows or denies the resource. We
>> >>>> could allow here several services which are asked in the order of
>> >>>> their service ranking until one of them provides a definite answer. If
>> >>>> none provides an answer, the resource is served - for compatibility.
>> >>>>
>> >>>> With this we should be able to easily hook on access control for such
>> >>>> providers not directly supporting it while staying compatible.
>> >>>>
>> >>>> Now, however there is a problem with the whole apprach - if a provider
>> >>>> is an ACLAwareResourceProvider we need to know internally if the
>> >>>> resource exists but the user is not allowed to access it, or if the
>> >>>> resource does not exist. Otherwise we potentially end up with a
>> >>>> resource at /somepath provided by provider A for user U1, and provided
>> >>>> by provider B for user U2 as user U2 is not allowed to access this
>> >>>> resource in provider A.
>> >>>>
>> >>>> WDYT?
>> >>>>
>> >>>> Regads
>> >>>> Carsten
>> >>>> --
>> >>>> Carsten Ziegeler
>> >>>> cziegeler@apache.org
>> >>>>
>> >>>
>> >>
>> >
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 22.11.11 11:15, "Mike Müller" <mi...@mysign.ch> wrote:
>We're at MySign thought about such a access control layer in Sling a few
>months ago. Mainly because we do have different resource providers
>without the possibility of ACLs and also because some access rules
>can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
>We do have such an access layer in our legacy framework and there
>we also have the possibility to define the access rules declarative (like
>ACLs) but also by somtehing like the proposed ResourceAccessController
>services.
Personally I think it is much better to put such additional ACL
implementations into the JCR (e.g. a custom Jackrabbit access control
provider). The problem is that anytime your code is using JCR (such as for
complex operations not possible through the simple resource API) your
sling-based access control won't be used at all.
Cheers,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
RE: [RT] Improving access control
Posted by Mike Müller <mi...@mysign.ch>.
Okay, I might be a little bit late in the discussion...
We're at MySign thought about such a access control layer in Sling a few
months ago. Mainly because we do have different resource providers
without the possibility of ACLs and also because some access rules
can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
We do have such an access layer in our legacy framework and there
we also have the possibility to define the access rules declarative (like
ACLs) but also by somtehing like the proposed ResourceAccessController
services.
I do share Justins fear, that we get poor performance if we do have to
call the JCR provider twice to once get to know if the user has access and
once to get the resource. But maybe the JCR resource provider can cache
the resource from the first call and the performance ist fine.
I think we should not design a general architecture for access controlling
an make the JCR a special case. I would prefer a "clean" design with only
one service interface for access controlling (without exceptions).
The approach where the ResourceProvider implements it's own access
control mechanism avoids the possibility for a special ResourceAccessController
to overwrite some access roles (like the example above with access
between 8.00 and 17.00). Plus, it would be less understandable than the
clean approach with just one entry point where access controlling is
taking place.
What I missed in the discussion so far is, that the proposed mechanisms
are only usable for read. I think a general access controller mechanism in
Sling should provide access controlling for read, write, modify and delete.
With such an architecture it would be much easier to control security aspects
of the application.
best regards
mike
> -----Original Message-----
> From: justinedelson@gmail.com [mailto:justinedelson@gmail.com] On Behalf Of Justin
> Edelson
> Sent: Tuesday, November 15, 2011 5:24 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] Improving access control
>
> Thanks for the clarification Julian. This makes more sense. I have two
> concerns with the variant you're describing:
>
> 1) It does not provide a way for ResourceProvider implementers to
> provide their own access control mechanism, which is one thing I
> really liked in Carsten's original proposal.
> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
> poor performance because the access control rules in the repository
> will be evaluated twice.
>
> Justin
>
> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding <js...@gmail.com> wrote:
> > Hi Justin
> >
> > Carsten's original proposal introduced two ways to handle access
> > control: ACLAwareResourceProvider and ResourceAccessController.
> >
> > The ACLAwareResourceProvider would act just like JCR Resources are
> > currently handled, i.e. with access control already enforced by the
> > underlying storage layer. The interface would merely indicate that
> > this ResourceProvider takes care of access control by itself (and
> > should presumably bypass any ResourceAccessController services).
> >
> > ResourceAccessController would be a new concept and interface, which
> > allows different implementations as services. A
> > ResourceAccessController (presumably again) indicates whether access
> > is granted or denied.
> >
> > The variation I propose is to drop the ACLAwareResourceProvider
> > concept and implement a ResourceAccessController for JCR resources
> > instead. The implementation would grant or deny access to a resource
> > based on ACLs in Jackrabbit.
> >
> > So a request for /foo would hit the SlingMainServlet, then the
> > Authenticator. Let's assume we now have a known user, we ask any
> > ResourceAccessController services if the user is granted access. If
> > access is denied, an appropriate response is sent (e.g. 403). If
> > access is granted, the ResourceProviders will be asked for the
> > resource. If the resource is unavailable, a 404 response can be sent,
> > otherwise Sling renders the resource.
> >
> > I'm not using the term ACL, as the ResourceAccessController are no
> > declarative lists of access control information. They can be
> > implemented in java, and one possible implementation are ACLs.
> >
> > Does this clarify my previous comment?
> >
> > Regards
> > Julian
> >
> >
> >
> > On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
> > <ju...@justinedelson.com> wrote:
> >> Hi Julian,
> >> I don't think I understand what you are suggesting here. Can you
> >> elaborate on what the code path would be in the case, for example, of
> >> a Bundle Resource Provider? If a bundle provides resources under, say,
> >> /mybundle, where would the ACL live and who would be responsible for
> >> evaluating it?
> >>
> >> I feel like I'm missing something obvious, so please bear with me :)
> >>
> >> Thanks,
> >> Justin
> >>
> >> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com> wrote:
> >>> Hi Carsten
> >>>
> >>> Interesting idea. Having access control handled by services allows
> >>> implementing arbitrary access control logic, which I would welcome. In
> >>> my experience, it's often difficult to express access control logic in
> >>> a declarative manner.
> >>>
> >>> I think we could further simplify the approach you describe. Leave the
> >>> ResourceProvider interface as it is and don't introduce an
> >>> ACLAwareResourceProvider interface. Instead have the JCR
> >>> ResourceProvider also implement ResourceAccessController. This
> >>> simplifies the design, while allowing to expose the same logic.
> >>> Additionally, it adds the possibility to layer additional access
> >>> control on top of Jackrabbit ACLs, thus allowing to combine the best
> >>> of both worlds (access control logic implemented in java +
> >>> Jackrabbit's declarative ACLs).
> >>>
> >>> Thoughts?
> >>>
> >>> Regards
> >>> Julian
> >>>
> >>>
> >>> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >>>> We support different resource providers, JCR, bundle, file etc. but so
> >>>> far only JCR implements access control based on the provided user.
> >>>> This leads to problems when resources are provided for example from a
> >>>> bundle or the file system as there is either no real ACL check is in
> >>>> place.
> >>>> I think we should change that!
> >>>>
> >>>> First, if a resource provider supports ACL checks like JCR it just
> >>>> should declare this by using a new interface ACLAwareResourceProvider
> >>>> (or any better name) which is just a marker interface.
> >>>> If a resource is provided by provider which does not declare this,
> >>>> well send the resource through a new service ResourceAccessControler
> >>>> (or a better name) which either allows or denies the resource. We
> >>>> could allow here several services which are asked in the order of
> >>>> their service ranking until one of them provides a definite answer. If
> >>>> none provides an answer, the resource is served - for compatibility.
> >>>>
> >>>> With this we should be able to easily hook on access control for such
> >>>> providers not directly supporting it while staying compatible.
> >>>>
> >>>> Now, however there is a problem with the whole apprach - if a provider
> >>>> is an ACLAwareResourceProvider we need to know internally if the
> >>>> resource exists but the user is not allowed to access it, or if the
> >>>> resource does not exist. Otherwise we potentially end up with a
> >>>> resource at /somepath provided by provider A for user U1, and provided
> >>>> by provider B for user U2 as user U2 is not allowed to access this
> >>>> resource in provider A.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Regads
> >>>> Carsten
> >>>> --
> >>>> Carsten Ziegeler
> >>>> cziegeler@apache.org
> >>>>
> >>>
> >>
> >
Re: [RT] Improving access control
Posted by Justin Edelson <ju...@justinedelson.com>.
Thanks for the clarification Julian. This makes more sense. I have two
concerns with the variant you're describing:
1) It does not provide a way for ResourceProvider implementers to
provide their own access control mechanism, which is one thing I
really liked in Carsten's original proposal.
2) In the case of the JCR ResourceProvider, it seems likely to lead to
poor performance because the access control rules in the repository
will be evaluated twice.
Justin
On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding <js...@gmail.com> wrote:
> Hi Justin
>
> Carsten's original proposal introduced two ways to handle access
> control: ACLAwareResourceProvider and ResourceAccessController.
>
> The ACLAwareResourceProvider would act just like JCR Resources are
> currently handled, i.e. with access control already enforced by the
> underlying storage layer. The interface would merely indicate that
> this ResourceProvider takes care of access control by itself (and
> should presumably bypass any ResourceAccessController services).
>
> ResourceAccessController would be a new concept and interface, which
> allows different implementations as services. A
> ResourceAccessController (presumably again) indicates whether access
> is granted or denied.
>
> The variation I propose is to drop the ACLAwareResourceProvider
> concept and implement a ResourceAccessController for JCR resources
> instead. The implementation would grant or deny access to a resource
> based on ACLs in Jackrabbit.
>
> So a request for /foo would hit the SlingMainServlet, then the
> Authenticator. Let's assume we now have a known user, we ask any
> ResourceAccessController services if the user is granted access. If
> access is denied, an appropriate response is sent (e.g. 403). If
> access is granted, the ResourceProviders will be asked for the
> resource. If the resource is unavailable, a 404 response can be sent,
> otherwise Sling renders the resource.
>
> I'm not using the term ACL, as the ResourceAccessController are no
> declarative lists of access control information. They can be
> implemented in java, and one possible implementation are ACLs.
>
> Does this clarify my previous comment?
>
> Regards
> Julian
>
>
>
> On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
> <ju...@justinedelson.com> wrote:
>> Hi Julian,
>> I don't think I understand what you are suggesting here. Can you
>> elaborate on what the code path would be in the case, for example, of
>> a Bundle Resource Provider? If a bundle provides resources under, say,
>> /mybundle, where would the ACL live and who would be responsible for
>> evaluating it?
>>
>> I feel like I'm missing something obvious, so please bear with me :)
>>
>> Thanks,
>> Justin
>>
>> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com> wrote:
>>> Hi Carsten
>>>
>>> Interesting idea. Having access control handled by services allows
>>> implementing arbitrary access control logic, which I would welcome. In
>>> my experience, it's often difficult to express access control logic in
>>> a declarative manner.
>>>
>>> I think we could further simplify the approach you describe. Leave the
>>> ResourceProvider interface as it is and don't introduce an
>>> ACLAwareResourceProvider interface. Instead have the JCR
>>> ResourceProvider also implement ResourceAccessController. This
>>> simplifies the design, while allowing to expose the same logic.
>>> Additionally, it adds the possibility to layer additional access
>>> control on top of Jackrabbit ACLs, thus allowing to combine the best
>>> of both worlds (access control logic implemented in java +
>>> Jackrabbit's declarative ACLs).
>>>
>>> Thoughts?
>>>
>>> Regards
>>> Julian
>>>
>>>
>>> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>> We support different resource providers, JCR, bundle, file etc. but so
>>>> far only JCR implements access control based on the provided user.
>>>> This leads to problems when resources are provided for example from a
>>>> bundle or the file system as there is either no real ACL check is in
>>>> place.
>>>> I think we should change that!
>>>>
>>>> First, if a resource provider supports ACL checks like JCR it just
>>>> should declare this by using a new interface ACLAwareResourceProvider
>>>> (or any better name) which is just a marker interface.
>>>> If a resource is provided by provider which does not declare this,
>>>> well send the resource through a new service ResourceAccessControler
>>>> (or a better name) which either allows or denies the resource. We
>>>> could allow here several services which are asked in the order of
>>>> their service ranking until one of them provides a definite answer. If
>>>> none provides an answer, the resource is served - for compatibility.
>>>>
>>>> With this we should be able to easily hook on access control for such
>>>> providers not directly supporting it while staying compatible.
>>>>
>>>> Now, however there is a problem with the whole apprach - if a provider
>>>> is an ACLAwareResourceProvider we need to know internally if the
>>>> resource exists but the user is not allowed to access it, or if the
>>>> resource does not exist. Otherwise we potentially end up with a
>>>> resource at /somepath provided by provider A for user U1, and provided
>>>> by provider B for user U2 as user U2 is not allowed to access this
>>>> resource in provider A.
>>>>
>>>> WDYT?
>>>>
>>>> Regads
>>>> Carsten
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
>>>>
>>>
>>
>
Re: [RT] Improving access control
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 13.11.11 22:35, "jsedding@gmail.com" <js...@gmail.com> wrote:
>ResourceAccessController would be a new concept and interface, which
>allows different implementations as services. A
>ResourceAccessController (presumably again) indicates whether access
>is granted or denied.
>
>The variation I propose is to drop the ACLAwareResourceProvider
>concept and implement a ResourceAccessController for JCR resources
>instead. The implementation would grant or deny access to a resource
>based on ACLs in Jackrabbit.
>...
>I'm not using the term ACL, as the ResourceAccessController are no
>declarative lists of access control information. They can be
>implemented in java, and one possible implementation are ACLs.
Hmm, doesn't this make ACL evaluation possibly much more difficult? It is
already not always straightforward (although perfectly specified) how
resource based or principal based ACLs inherit, what an effective ACL is
made of etc. Allowing yet another mechanism to basically override the JCR
access control "from the outside" doesn't sound good to me.
Cheers,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: [RT] Improving access control
Posted by Julian Sedding <js...@gmail.com>.
Hi Justin
Carsten's original proposal introduced two ways to handle access
control: ACLAwareResourceProvider and ResourceAccessController.
The ACLAwareResourceProvider would act just like JCR Resources are
currently handled, i.e. with access control already enforced by the
underlying storage layer. The interface would merely indicate that
this ResourceProvider takes care of access control by itself (and
should presumably bypass any ResourceAccessController services).
ResourceAccessController would be a new concept and interface, which
allows different implementations as services. A
ResourceAccessController (presumably again) indicates whether access
is granted or denied.
The variation I propose is to drop the ACLAwareResourceProvider
concept and implement a ResourceAccessController for JCR resources
instead. The implementation would grant or deny access to a resource
based on ACLs in Jackrabbit.
So a request for /foo would hit the SlingMainServlet, then the
Authenticator. Let's assume we now have a known user, we ask any
ResourceAccessController services if the user is granted access. If
access is denied, an appropriate response is sent (e.g. 403). If
access is granted, the ResourceProviders will be asked for the
resource. If the resource is unavailable, a 404 response can be sent,
otherwise Sling renders the resource.
I'm not using the term ACL, as the ResourceAccessController are no
declarative lists of access control information. They can be
implemented in java, and one possible implementation are ACLs.
Does this clarify my previous comment?
Regards
Julian
On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
<ju...@justinedelson.com> wrote:
> Hi Julian,
> I don't think I understand what you are suggesting here. Can you
> elaborate on what the code path would be in the case, for example, of
> a Bundle Resource Provider? If a bundle provides resources under, say,
> /mybundle, where would the ACL live and who would be responsible for
> evaluating it?
>
> I feel like I'm missing something obvious, so please bear with me :)
>
> Thanks,
> Justin
>
> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com> wrote:
>> Hi Carsten
>>
>> Interesting idea. Having access control handled by services allows
>> implementing arbitrary access control logic, which I would welcome. In
>> my experience, it's often difficult to express access control logic in
>> a declarative manner.
>>
>> I think we could further simplify the approach you describe. Leave the
>> ResourceProvider interface as it is and don't introduce an
>> ACLAwareResourceProvider interface. Instead have the JCR
>> ResourceProvider also implement ResourceAccessController. This
>> simplifies the design, while allowing to expose the same logic.
>> Additionally, it adds the possibility to layer additional access
>> control on top of Jackrabbit ACLs, thus allowing to combine the best
>> of both worlds (access control logic implemented in java +
>> Jackrabbit's declarative ACLs).
>>
>> Thoughts?
>>
>> Regards
>> Julian
>>
>>
>> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> We support different resource providers, JCR, bundle, file etc. but so
>>> far only JCR implements access control based on the provided user.
>>> This leads to problems when resources are provided for example from a
>>> bundle or the file system as there is either no real ACL check is in
>>> place.
>>> I think we should change that!
>>>
>>> First, if a resource provider supports ACL checks like JCR it just
>>> should declare this by using a new interface ACLAwareResourceProvider
>>> (or any better name) which is just a marker interface.
>>> If a resource is provided by provider which does not declare this,
>>> well send the resource through a new service ResourceAccessControler
>>> (or a better name) which either allows or denies the resource. We
>>> could allow here several services which are asked in the order of
>>> their service ranking until one of them provides a definite answer. If
>>> none provides an answer, the resource is served - for compatibility.
>>>
>>> With this we should be able to easily hook on access control for such
>>> providers not directly supporting it while staying compatible.
>>>
>>> Now, however there is a problem with the whole apprach - if a provider
>>> is an ACLAwareResourceProvider we need to know internally if the
>>> resource exists but the user is not allowed to access it, or if the
>>> resource does not exist. Otherwise we potentially end up with a
>>> resource at /somepath provided by provider A for user U1, and provided
>>> by provider B for user U2 as user U2 is not allowed to access this
>>> resource in provider A.
>>>
>>> WDYT?
>>>
>>> Regads
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>>
>>
>
Re: [RT] Improving access control
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Julian,
I don't think I understand what you are suggesting here. Can you
elaborate on what the code path would be in the case, for example, of
a Bundle Resource Provider? If a bundle provides resources under, say,
/mybundle, where would the ACL live and who would be responsible for
evaluating it?
I feel like I'm missing something obvious, so please bear with me :)
Thanks,
Justin
On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <js...@gmail.com> wrote:
> Hi Carsten
>
> Interesting idea. Having access control handled by services allows
> implementing arbitrary access control logic, which I would welcome. In
> my experience, it's often difficult to express access control logic in
> a declarative manner.
>
> I think we could further simplify the approach you describe. Leave the
> ResourceProvider interface as it is and don't introduce an
> ACLAwareResourceProvider interface. Instead have the JCR
> ResourceProvider also implement ResourceAccessController. This
> simplifies the design, while allowing to expose the same logic.
> Additionally, it adds the possibility to layer additional access
> control on top of Jackrabbit ACLs, thus allowing to combine the best
> of both worlds (access control logic implemented in java +
> Jackrabbit's declarative ACLs).
>
> Thoughts?
>
> Regards
> Julian
>
>
> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> We support different resource providers, JCR, bundle, file etc. but so
>> far only JCR implements access control based on the provided user.
>> This leads to problems when resources are provided for example from a
>> bundle or the file system as there is either no real ACL check is in
>> place.
>> I think we should change that!
>>
>> First, if a resource provider supports ACL checks like JCR it just
>> should declare this by using a new interface ACLAwareResourceProvider
>> (or any better name) which is just a marker interface.
>> If a resource is provided by provider which does not declare this,
>> well send the resource through a new service ResourceAccessControler
>> (or a better name) which either allows or denies the resource. We
>> could allow here several services which are asked in the order of
>> their service ranking until one of them provides a definite answer. If
>> none provides an answer, the resource is served - for compatibility.
>>
>> With this we should be able to easily hook on access control for such
>> providers not directly supporting it while staying compatible.
>>
>> Now, however there is a problem with the whole apprach - if a provider
>> is an ACLAwareResourceProvider we need to know internally if the
>> resource exists but the user is not allowed to access it, or if the
>> resource does not exist. Otherwise we potentially end up with a
>> resource at /somepath provided by provider A for user U1, and provided
>> by provider B for user U2 as user U2 is not allowed to access this
>> resource in provider A.
>>
>> WDYT?
>>
>> Regads
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/12 Julian Sedding <js...@gmail.com>:
> Hi Carsten
>
> Interesting idea. Having access control handled by services allows
> implementing arbitrary access control logic, which I would welcome. In
> my experience, it's often difficult to express access control logic in
> a declarative manner.
>
> I think we could further simplify the approach you describe. Leave the
> ResourceProvider interface as it is and don't introduce an
> ACLAwareResourceProvider interface. Instead have the JCR
> ResourceProvider also implement ResourceAccessController. This
> simplifies the design, while allowing to expose the same logic.
> Additionally, it adds the possibility to layer additional access
> control on top of Jackrabbit ACLs, thus allowing to combine the best
> of both worlds (access control logic implemented in java +
> Jackrabbit's declarative ACLs).
Yes, sounds like an interesting idea - it would also solve the problem
to distinguish between a none existing resource and denied access in
the JCR case.
Regards
Carsten
>
> Thoughts?
>
> Regards
> Julian
>
>
> On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> We support different resource providers, JCR, bundle, file etc. but so
>> far only JCR implements access control based on the provided user.
>> This leads to problems when resources are provided for example from a
>> bundle or the file system as there is either no real ACL check is in
>> place.
>> I think we should change that!
>>
>> First, if a resource provider supports ACL checks like JCR it just
>> should declare this by using a new interface ACLAwareResourceProvider
>> (or any better name) which is just a marker interface.
>> If a resource is provided by provider which does not declare this,
>> well send the resource through a new service ResourceAccessControler
>> (or a better name) which either allows or denies the resource. We
>> could allow here several services which are asked in the order of
>> their service ranking until one of them provides a definite answer. If
>> none provides an answer, the resource is served - for compatibility.
>>
>> With this we should be able to easily hook on access control for such
>> providers not directly supporting it while staying compatible.
>>
>> Now, however there is a problem with the whole apprach - if a provider
>> is an ACLAwareResourceProvider we need to know internally if the
>> resource exists but the user is not allowed to access it, or if the
>> resource does not exist. Otherwise we potentially end up with a
>> resource at /somepath provided by provider A for user U1, and provided
>> by provider B for user U2 as user U2 is not allowed to access this
>> resource in provider A.
>>
>> WDYT?
>>
>> Regads
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Julian Sedding <js...@gmail.com>.
Hi Carsten
Interesting idea. Having access control handled by services allows
implementing arbitrary access control logic, which I would welcome. In
my experience, it's often difficult to express access control logic in
a declarative manner.
I think we could further simplify the approach you describe. Leave the
ResourceProvider interface as it is and don't introduce an
ACLAwareResourceProvider interface. Instead have the JCR
ResourceProvider also implement ResourceAccessController. This
simplifies the design, while allowing to expose the same logic.
Additionally, it adds the possibility to layer additional access
control on top of Jackrabbit ACLs, thus allowing to combine the best
of both worlds (access control logic implemented in java +
Jackrabbit's declarative ACLs).
Thoughts?
Regards
Julian
On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> We support different resource providers, JCR, bundle, file etc. but so
> far only JCR implements access control based on the provided user.
> This leads to problems when resources are provided for example from a
> bundle or the file system as there is either no real ACL check is in
> place.
> I think we should change that!
>
> First, if a resource provider supports ACL checks like JCR it just
> should declare this by using a new interface ACLAwareResourceProvider
> (or any better name) which is just a marker interface.
> If a resource is provided by provider which does not declare this,
> well send the resource through a new service ResourceAccessControler
> (or a better name) which either allows or denies the resource. We
> could allow here several services which are asked in the order of
> their service ranking until one of them provides a definite answer. If
> none provides an answer, the resource is served - for compatibility.
>
> With this we should be able to easily hook on access control for such
> providers not directly supporting it while staying compatible.
>
> Now, however there is a problem with the whole apprach - if a provider
> is an ACLAwareResourceProvider we need to know internally if the
> resource exists but the user is not allowed to access it, or if the
> resource does not exist. Otherwise we potentially end up with a
> resource at /somepath provided by provider A for user U1, and provided
> by provider B for user U2 as user U2 is not allowed to access this
> resource in provider A.
>
> WDYT?
>
> Regads
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [RT] Improving access control
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/13 Justin Edelson <ju...@justinedelson.com>:
>>
>> Now, however there is a problem with the whole apprach - if a provider
>> is an ACLAwareResourceProvider we need to know internally if the
>> resource exists but the user is not allowed to access it, or if the
>> resource does not exist. Otherwise we potentially end up with a
>> resource at /somepath provided by provider A for user U1, and provided
>> by provider B for user U2 as user U2 is not allowed to access this
>> resource in provider A.
>
> Playing devil's advocate here... why is this a problem? This seems
> like it might be a good thing in some cases.
>
Yes I thought about that as well and honestly, I'm not sure if it
really poses a problem in reality though it doesn't look like a good
feature. It basically would mean that different users requesting the
same resource might end up with a different resource being served.
That seems wrong to me - i see potential use case where you might want
to serve kind of a placeholder resource if the user is not allowed to
access the original resource, but this can already be solved in other
ways today.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] Improving access control
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Carsten,
On Fri, Nov 11, 2011 at 7:29 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> We support different resource providers, JCR, bundle, file etc. but so
> far only JCR implements access control based on the provided user.
> This leads to problems when resources are provided for example from a
> bundle or the file system as there is either no real ACL check is in
> place.
> I think we should change that!
+1
>
> First, if a resource provider supports ACL checks like JCR it just
> should declare this by using a new interface ACLAwareResourceProvider
> (or any better name) which is just a marker interface.
> If a resource is provided by provider which does not declare this,
> well send the resource through a new service ResourceAccessControler
> (or a better name) which either allows or denies the resource. We
> could allow here several services which are asked in the order of
> their service ranking until one of them provides a definite answer. If
> none provides an answer, the resource is served - for compatibility.
>
I like the general design here. I suspect this also means we're going
to have to expand the ResourceResolver API a bit to include not just
the userId but some notion of groups as both an
ACLAwareResourceProvider and the ResourceAccessController will likely
want to make access control decisions based on more that the userId.
Perhaps we can use UserAdmin for this.
> With this we should be able to easily hook on access control for such
> providers not directly supporting it while staying compatible.
>
> Now, however there is a problem with the whole apprach - if a provider
> is an ACLAwareResourceProvider we need to know internally if the
> resource exists but the user is not allowed to access it, or if the
> resource does not exist. Otherwise we potentially end up with a
> resource at /somepath provided by provider A for user U1, and provided
> by provider B for user U2 as user U2 is not allowed to access this
> resource in provider A.
Playing devil's advocate here... why is this a problem? This seems
like it might be a good thing in some cases.
Justin
>
> WDYT?
>
> Regads
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [RT] Improving access control
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 23.11.2011 um 14:01 schrieb Bertrand Delacretaz:
> On Wed, Nov 23, 2011 at 9:41 AM, Felix Meschberger <fm...@adobe.com> wrote:
>> ...I suggest, we extend the Resource API as follows:
>>
>> boolean ResourceResolver.hasPermission(String absPath, String action);
>> boolean ResourceProvider.hasPermission(String absPath, String action);
>>
>> ...
>> In addition, we would define a set of actions use full in terms of Sling: cread, read, update , delete (aka CRUD) plus (maybe) execute (for calling scripts and servlets)....
>
> This sounds a lot like reinventing JCR...why not use the existing JCR
> AccessControlManager API then?
Absolutely not. This is just a single method (which is similar to Session.checkPermission). This is far away from JCR's AccessControlManager, which I explicitly don't want to duplicate. I want to keep it simple and in the context of Sling.
Regards
Felix
> See [1] and [2].
>
> That API is only about String paths AFAICS, it defines a number of
> standard privilege names and allows for additional privilege names -
> so a non-JCR ResourceProvider could very well use it IMO.
>
> I haven't looked at all the details but we can probably just define a
> new AccessControlManagerProvider API, that returns a JCR
> AccessControlManager, and the ResourceResolver would use it for
> ResourceProviders that implement it.
>
> -Bertrand
>
> [1] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/AccessControlManager.html
>
> [2] http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html
Re: [RT] Improving access control
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 23, 2011 at 9:41 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...I suggest, we extend the Resource API as follows:
>
> boolean ResourceResolver.hasPermission(String absPath, String action);
> boolean ResourceProvider.hasPermission(String absPath, String action);
>
>...
> In addition, we would define a set of actions use full in terms of Sling: cread, read, update , delete (aka CRUD) plus (maybe) execute (for calling scripts and servlets)....
This sounds a lot like reinventing JCR...why not use the existing JCR
AccessControlManager API then?
See [1] and [2].
That API is only about String paths AFAICS, it defines a number of
standard privilege names and allows for additional privilege names -
so a non-JCR ResourceProvider could very well use it IMO.
I haven't looked at all the details but we can probably just define a
new AccessControlManagerProvider API, that returns a JCR
AccessControlManager, and the ResourceResolver would use it for
ResourceProviders that implement it.
-Bertrand
[1] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/AccessControlManager.html
[2] http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html
Re: [RT] Improving access control
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Sorry, too, for being late at the party ...
I think we should
* keep it simple
* not try to duplicate existing stuff
* ensure consistency
Thus, I think the Sling Resource API should not impose another layer of access control checks to what is already implemented in ResourceProvider implementations. Rather, I think the Sling Resource API should just expose the same checks. Just like the JCR 1.0 Session.checkPermission method does.
So I suggest, we extend the Resource API as follows:
boolean ResourceResolver.hasPermission(String absPath, String action);
boolean ResourceProvider.hasPermission(String absPath, String action);
Applications may call the ResourceResolver.hasPermission method to check whether the given action is allowed on a (potential) resource at the given absolute path.
The ResourceResolver implementation would then select the ResourceProvider services to call in the same way as they are selected already to implement the ResourceResolver.getResource(String) method. This allows delegation of the hasPermission implementation from the path-wise-best-matching provider to the root provider (generally JCR).
In addition, we would define a set of actions use full in terms of Sling: cread, read, update , delete (aka CRUD) plus (maybe) execute (for calling scripts and servlets).
The Sling Resource API explicitly does not state how access control is implemented and configured. This remains part of the ResourceProvider's implementation detail.
Regards
Felix
Am 12.11.2011 um 04:29 schrieb Carsten Ziegeler:
> We support different resource providers, JCR, bundle, file etc. but so
> far only JCR implements access control based on the provided user.
> This leads to problems when resources are provided for example from a
> bundle or the file system as there is either no real ACL check is in
> place.
> I think we should change that!
>
> First, if a resource provider supports ACL checks like JCR it just
> should declare this by using a new interface ACLAwareResourceProvider
> (or any better name) which is just a marker interface.
> If a resource is provided by provider which does not declare this,
> well send the resource through a new service ResourceAccessControler
> (or a better name) which either allows or denies the resource. We
> could allow here several services which are asked in the order of
> their service ranking until one of them provides a definite answer. If
> none provides an answer, the resource is served - for compatibility.
>
> With this we should be able to easily hook on access control for such
> providers not directly supporting it while staying compatible.
>
> Now, however there is a problem with the whole apprach - if a provider
> is an ACLAwareResourceProvider we need to know internally if the
> resource exists but the user is not allowed to access it, or if the
> resource does not exist. Otherwise we potentially end up with a
> resource at /somepath provided by provider A for user U1, and provided
> by provider B for user U2 as user U2 is not allowed to access this
> resource in provider A.
>
> WDYT?
>
> Regads
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org