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 2013/03/07 11:40:56 UTC
[RT] ResourceProviderDecorator
Hi,
as recent discussion showed, there might be use cases for a resource
provider decorator. A decorator can be used to add functionality
across several resource providers. E.g. this would simplify securing
resource providers which don't support access checks ootb, like the
file resource provider or the MongoDB resource provider.
Decorating a resource provider is not as trivial as decorating a
resource because a provider might come in different flavours =
implement additional functionality through sub interfaces.
So I think just having a single decorate method is too error-prone as
the implementation would have to check whether a resource provider
implements those interfaces and construct a corresponding resource
provider.
Therefore I propose we add a simple interface:
public interface ResourceProviderDecorator {
ResourceProvider decorate(final ResourceProvider provider);
AttributableResourceProvider decorate(final
AttributableResourceProvider provider);
ModifyingResourceProvider decorate(final ModifyingResourceProvider
provider);
QueriableResourceProvider decorate(final QueriableResourceProvider
provider);
DynamicResourceProvider decorate(final DynamicResourceProvider provider);
}
which allows to decorate each separately. At the same time we add
wrapper implementations for all of the above which delegate to the
passed in resource provider. This makes the implementation much
easier.
The decorators are ordered by their service ranking and called in this order.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/7 Carsten Ziegeler <cz...@apache.org>:
> Therefore I propose we add a simple interface:
> public interface ResourceProviderDecorator {
>
> ResourceProvider decorate(final ResourceProvider provider);
>
> AttributableResourceProvider decorate(final
> AttributableResourceProvider provider);
>
> ModifyingResourceProvider decorate(final ModifyingResourceProvider
> provider);
>
> QueriableResourceProvider decorate(final QueriableResourceProvider
> provider);
>
> DynamicResourceProvider decorate(final DynamicResourceProvider provider);
> }
Rethinking this, I don't think we should decorate a
DynamicResourceProvider. A dynamic resource provider is used to find
out if the provider (or the underlying storage) is still alive and
when the resource resolver is closed, it's used to close the
connection (or session).
And I don't think we need to decorate an AttributableResourceProvider
either - these are used to provide additional attributes to the
resource resolver. So far I don't see any use case here.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Ian Boston <ie...@tfd.co.uk>.
On 8 March 2013 19:52, Carsten Ziegeler <cz...@apache.org> wrote:
> 2013/3/8 Ian Boston <ie...@tfd.co.uk>:
> sources are navigable.
>>
>> eg
>> /a is managed by a JCR Resource Provider wrapped in a ResourceProviderDecorator
>>
>> /a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
>> /a/b/c/d/e is allowed by the ResourceProviderDecorator
>>
>> Node n = resourceResolver.getResource("/a/b/c/d/e").adaptTo(Node.class);
>>
>> ... 20 lines of code ...
>>
>> Node breach = n.getChild("f");
>>
> I think Bertrand summarized it very well in his recent post - you
> wouldn't implement ACL checks for JCR with this, but for resource
> providers not having ACLs - and in that case you probably don't have
> an adaption mechanism to an object which allows you tree traversal, so
> there is no Node equivalent.
I'm ok with all the decorators if the guidance is rephrased:
"If the system the ResourceProvider provides Resources from implements
and exposes tree traversal via an adaption mechanism it is the
responsibility of the ResourceProvider or underlying system to
implement an appropriate level of security."
(by implication, if the implementor of the ResourceProvider chooses to
ignore the guidance, on their head be it.)
I think that covers JCR and any other system that might expose objects
that are capable of tree traversal. They do exist.
Best Regards
Ian
Re: [RT] ResourceProviderDecorator
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/8 Ian Boston <ie...@tfd.co.uk>:
sources are navigable.
>
> eg
> /a is managed by a JCR Resource Provider wrapped in a ResourceProviderDecorator
>
> /a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
> /a/b/c/d/e is allowed by the ResourceProviderDecorator
>
> Node n = resourceResolver.getResource("/a/b/c/d/e").adaptTo(Node.class);
>
> ... 20 lines of code ...
>
> Node breach = n.getChild("f");
>
I think Bertrand summarized it very well in his recent post - you
wouldn't implement ACL checks for JCR with this, but for resource
providers not having ACLs - and in that case you probably don't have
an adaption mechanism to an object which allows you tree traversal, so
there is no Node equivalent.
And if you do things like Mike want's to do, well you're on your own
and you know what you're doing. With the flexibility of
ResourceProviders and ResourceDecorators we already have enough
munition for people to implement such things. A resource decorator is
no different from these things, but makes some use cases way easier
while not really introducing a new "hole"
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/8 Bertrand Delacretaz <bd...@apache.org>:
>
> What I definitely want to keep is the "if using JCR, don't use any
> other access control mechanism" constraint, and if people do otherwise
> it's their problem.
Exactly - that summarizes the whole discussion very good :)
> You can probably work around that restriction
> today anyway, by implementing custom ResourceProviders that wrap
> existing ones,
Right
> so why not make that clearer and make option 3) above
> possible.
>
+1
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Angela,
On Wed, Mar 13, 2013 at 12:15 PM, Angela Schreiber <an...@adobe.com> wrote:
>> What I definitely want to keep is the "if using JCR, don't use any
>> other access control mechanism" constraint, and if people do otherwise
>> it's their problem.
>
> no this is not the case. IMHO you are completely mistaken here.
> if our customers 'do otherwise' (and they usually do for various
> reasons) it falls back on our products no matter what....
While I agree with the general idea, there's no way to make a system
fully immune to abuse from stupid users who have all the keys (aka
admin user in our case) - it's often a balance between useful and
dangerous functionality, and between trusting and educating users.
This well known command line russian roulette is a good example. I
didn't say anyone should run it, and especially not as root, but you
cannot blame linux/unix system designers for it, all its components
are otherwise useful.
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
-Bertrand
Re: [RT] ResourceProviderDecorator
Posted by Angela Schreiber <an...@adobe.com>.
hi bertrand
> What I definitely want to keep is the "if using JCR, don't use any
> other access control mechanism" constraint, and if people do otherwise
> it's their problem.
no this is not the case. IMHO you are completely mistaken here.
if our customers 'do otherwise' (and they usually do for various
reasons) it falls back on our products no matter what.
it's our responsibility to make sure that our products
are secure out of the box. making features available and
usable that compromise this, is not only a threat for an
individual customer but for us as a company.
kind regards
angela
Re: [RT] ResourceProviderDecorator
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Mar 8, 2013 at 8:53 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...How will the ResourceProviderDecorator protect from navigating using a
> native object of the ResourceProvider impl acquired using an adaptTo ?...
By native object I assume you mean a JCR Node for example?
If yes you're right that whatever a ResourceProviderDecorator does to
prevent access to a Resource, by adapting another Resource to a JCR
Node you can bypass that.
That's why several of us want to avoid using ResourceProviderDecorator
or any similar mechanism for access control when using Sling over a
JCR repository.
As far as access control is concerned, I see three options for running Sling:
1) Running on a JCR repository - access control is fully delegated to
the repository, maybe disabling ResourceProviderDecorator with a
default configuration, to make sure people only use that if they know
what they're doing.
2) Running on non-JCR content stores, and not caring about access
control. There are valid use cases for that, especially if the content
store is fed from a different system and Sling only has readonly
access to it (think a Solr index that's fed from incoming media files
for example). This is of course already doable today, as Sling does
not do any access control by itself.
3) Running on non-JCR content stores which do not support access
control, and implementing access control at the application layer.
This is where ResourceProviderDecorator can help, and it can be as
simple as saying "anonymous only has read access to /content and
/static, other users have full read-write access" which can be valid
combined with http front-end restrictions.
What I definitely want to keep is the "if using JCR, don't use any
other access control mechanism" constraint, and if people do otherwise
it's their problem. You can probably work around that restriction
today anyway, by implementing custom ResourceProviders that wrap
existing ones, so why not make that clearer and make option 3) above
possible.
-Bertrand
Re: [RT] ResourceProviderDecorator
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/8 Ian Boston <ie...@tfd.co.uk>:
>
> Ok, next stupid question :)
>
> How will the ResourceProviderDecorator protect from navigating using a
> native object of the ResourceProvider impl acquired using an adaptTo ?
>
Another stupid question :)
How does a ResourceDecorator prevent such things?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Ian Boston <ie...@tfd.co.uk>.
On 8 March 2013 18:27, Mike Müller <mi...@mysign.ch> wrote:
>> Sorry for asking a stupid question, but why would a ResourceProvider
>> that delivered resources subject to security, not implement it that
>> security and cover the use cases required as a part of its
>> implementation ?
>>
>> 1 Allowing insecure ResourceProviders to exist with the intention of
>> decorating them feels to be like a dangerous path to take. If they are
>> used without decoration they become unsafe.
>>
>> 2 If the use case is an additional layer of security ontop of a secure
>> resource provider (eg a rules based ACL), then I can see that there
>> might be a genuine need, but I have to ask why isn't the security part
>> of the resource provider itself because its too easy to circumvent
>> when resources are navigable.
>
>
> The use case is different: We will (or should) have ResourceProviders for
> non ACL aware storages like MongoDB, Cassandra (or like Bertrand
> mentioned SolR) etc. in the future. I don't think it would make sense to
> implement ACLs or some other security mechanism in each of these
> ResourceProviders. And not using them because they do not have a
> ACL mechanism is maybe not the right way to go. Sling should not be
> only a JCR frontend in the future, that's why I think we should be able to
> deal with this new sort of non ACL aware ResourceProviders and at this
> point the ResourceProviderDecorator or ResourceAccessGate (or whatever)
> comes in. It is not designed to be used as a ACL layer on top of JCR,
> there we don't need it.
Ok, next stupid question :)
How will the ResourceProviderDecorator protect from navigating using a
native object of the ResourceProvider impl acquired using an adaptTo ?
Best Regards
Ian
>
> best regards
> mike
RE: [RT] ResourceProviderDecorator
Posted by Mike Müller <mi...@mysign.ch>.
> Sorry for asking a stupid question, but why would a ResourceProvider
> that delivered resources subject to security, not implement it that
> security and cover the use cases required as a part of its
> implementation ?
>
> 1 Allowing insecure ResourceProviders to exist with the intention of
> decorating them feels to be like a dangerous path to take. If they are
> used without decoration they become unsafe.
>
> 2 If the use case is an additional layer of security ontop of a secure
> resource provider (eg a rules based ACL), then I can see that there
> might be a genuine need, but I have to ask why isn't the security part
> of the resource provider itself because its too easy to circumvent
> when resources are navigable.
The use case is different: We will (or should) have ResourceProviders for
non ACL aware storages like MongoDB, Cassandra (or like Bertrand
mentioned SolR) etc. in the future. I don't think it would make sense to
implement ACLs or some other security mechanism in each of these
ResourceProviders. And not using them because they do not have a
ACL mechanism is maybe not the right way to go. Sling should not be
only a JCR frontend in the future, that's why I think we should be able to
deal with this new sort of non ACL aware ResourceProviders and at this
point the ResourceProviderDecorator or ResourceAccessGate (or whatever)
comes in. It is not designed to be used as a ACL layer on top of JCR,
there we don't need it.
best regards
mike
Re: [RT] ResourceProviderDecorator
Posted by Ian Boston <ie...@tfd.co.uk>.
On 7 March 2013 21:40, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> as recent discussion showed, there might be use cases for a resource
> provider decorator. A decorator can be used to add functionality
> across several resource providers. E.g. this would simplify securing
> resource providers which don't support access checks ootb, like the
> file resource provider or the MongoDB resource provider.
>
> Decorating a resource provider is not as trivial as decorating a
> resource because a provider might come in different flavours =
> implement additional functionality through sub interfaces.
> So I think just having a single decorate method is too error-prone as
> the implementation would have to check whether a resource provider
> implements those interfaces and construct a corresponding resource
> provider.
>
> Therefore I propose we add a simple interface:
> public interface ResourceProviderDecorator {
>
> ResourceProvider decorate(final ResourceProvider provider);
>
> AttributableResourceProvider decorate(final
> AttributableResourceProvider provider);
>
> ModifyingResourceProvider decorate(final ModifyingResourceProvider
> provider);
>
> QueriableResourceProvider decorate(final QueriableResourceProvider
> provider);
>
> DynamicResourceProvider decorate(final DynamicResourceProvider provider);
> }
>
> which allows to decorate each separately. At the same time we add
> wrapper implementations for all of the above which delegate to the
> passed in resource provider. This makes the implementation much
> easier.
>
> The decorators are ordered by their service ranking and called in this order.
>
> WDYT?
Sorry for asking a stupid question, but why would a ResourceProvider
that delivered resources subject to security, not implement it that
security and cover the use cases required as a part of its
implementation ?
1 Allowing insecure ResourceProviders to exist with the intention of
decorating them feels to be like a dangerous path to take. If they are
used without decoration they become unsafe.
2 If the use case is an additional layer of security ontop of a secure
resource provider (eg a rules based ACL), then I can see that there
might be a genuine need, but I have to ask why isn't the security part
of the resource provider itself because its too easy to circumvent
when resources are navigable.
eg
/a is managed by a JCR Resource Provider wrapped in a ResourceProviderDecorator
/a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
/a/b/c/d/e is allowed by the ResourceProviderDecorator
Node n = resourceResolver.getResource("/a/b/c/d/e").adaptTo(Node.class);
... 20 lines of code ...
Node breach = n.getChild("f");
Replace JCR and Node.class with any storage system that allows child
navigation and a resource.adapto(NodeLikeClass.class).
The only way I can see of making this safe is to block adaptTo on a
resource delivered via this route, and that would be a backwards step.
Sorry.
Ian
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Basically, I like the idea of ResourceProviderDecorator to augment and increase the functionality of a decorated ResourceProvider. But we should not sell it as a security device, which it is not.
Why not ?
(1) For the reasons explained by Ian: If you adaptTo the resource to the underlying data (such as File in a "protected" FileSystemResourceProvider) you get to requested "resources" outside of protection. Right, you leave the save haven of the Resource API but you get at resources, the ResourceProviderDecorator would like to protect you from. The only (partial) help would be for the ResourceProviderDecorator to prevent resources from being adapted to the underlying data structure and thus know about the decorated ResourceProviders.
(2) It IMHO violates a simple security principle: Something secure should prevent access if there is a failure. In the case of a ResourceProviderDecorator, the failure could be absence of the ResourceProviderDecorator (a service may be gone at any time). The problem with such a failure is, that resources become accessible !
So, here's my position: ResourceProviderDecorator yes, but not as a means for security.
I think security and access protection is something that the ResourceProvider must take care of and must be aware of. Be it by using a protected data store (as in the case of the JCR based ResourceProvider) or by implementing protection in the ResourceProvider itself and being aware of what it means to implement the adaptTo methods.
I could imagine, that we implement a service, that may be used by security aware ResourceProviders to query for access control: So the AccessGate proposed by Mike could in fact be a service to be used by ResourceProviders to implement access control. The advantage would be that if the AccessGate service is missing, the ResourceProvider (and its resources) would know and could act accordingly.
Regards
Felix
Am 07.03.2013 um 11:40 schrieb Carsten Ziegeler:
> Hi,
>
> as recent discussion showed, there might be use cases for a resource
> provider decorator. A decorator can be used to add functionality
> across several resource providers. E.g. this would simplify securing
> resource providers which don't support access checks ootb, like the
> file resource provider or the MongoDB resource provider.
>
> Decorating a resource provider is not as trivial as decorating a
> resource because a provider might come in different flavours =
> implement additional functionality through sub interfaces.
> So I think just having a single decorate method is too error-prone as
> the implementation would have to check whether a resource provider
> implements those interfaces and construct a corresponding resource
> provider.
>
> Therefore I propose we add a simple interface:
> public interface ResourceProviderDecorator {
>
> ResourceProvider decorate(final ResourceProvider provider);
>
> AttributableResourceProvider decorate(final
> AttributableResourceProvider provider);
>
> ModifyingResourceProvider decorate(final ModifyingResourceProvider
> provider);
>
> QueriableResourceProvider decorate(final QueriableResourceProvider
> provider);
>
> DynamicResourceProvider decorate(final DynamicResourceProvider provider);
> }
>
> which allows to decorate each separately. At the same time we add
> wrapper implementations for all of the above which delegate to the
> passed in resource provider. This makes the implementation much
> easier.
>
> The decorators are ordered by their service ranking and called in this order.
>
> WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] ResourceProviderDecorator
Posted by Ian Boston <ie...@tfd.co.uk>.
On 8 March 2013 19:13, Carsten Ziegeler <cz...@apache.org> wrote:
> I have another use case for the decorator, it's possible to "enhance"
> resources with data coming from a different location, so for example
> for the file resource provider I could store metadata about a file
> somewhere else and combine the information. This would also support
> updating/creating the metadata.
> This is also implementable by implementing a new resource provider
> which combines the input of two other resource providers, but a
> decorator would make this nicer/easier.
That is a valid use case for a decorator pattern as doesn't change or
confuse where the responsibility for applying access control lies.
I have nothing against the decorator pattern per se, I am just worried
that using it to patch ResourceProviders that have no security, with
security will be hard to achieve without introducing holes. Obviously,
once its introduced it can be used anyway the downstream developer
feels fit, but I don't thing we should encourage a pattern that could
result in a application that is not intrinsically safe. Sling has a
very wide security footprint above the ResourceResolver. The
Jackrabbit implementation has protected us from needing to think too
deeply about this upto now.
Best Regards
Ian
>
> Carsten
>
> 2013/3/7 Carsten Ziegeler <cz...@apache.org>:
>> Hi,
>>
>> as recent discussion showed, there might be use cases for a resource
>> provider decorator. A decorator can be used to add functionality
>> across several resource providers. E.g. this would simplify securing
>> resource providers which don't support access checks ootb, like the
>> file resource provider or the MongoDB resource provider.
>>
>> Decorating a resource provider is not as trivial as decorating a
>> resource because a provider might come in different flavours =
>> implement additional functionality through sub interfaces.
>> So I think just having a single decorate method is too error-prone as
>> the implementation would have to check whether a resource provider
>> implements those interfaces and construct a corresponding resource
>> provider.
>>
>> Therefore I propose we add a simple interface:
>> public interface ResourceProviderDecorator {
>>
>> ResourceProvider decorate(final ResourceProvider provider);
>>
>> AttributableResourceProvider decorate(final
>> AttributableResourceProvider provider);
>>
>> ModifyingResourceProvider decorate(final ModifyingResourceProvider
>> provider);
>>
>> QueriableResourceProvider decorate(final QueriableResourceProvider
>> provider);
>>
>> DynamicResourceProvider decorate(final DynamicResourceProvider provider);
>> }
>>
>> which allows to decorate each separately. At the same time we add
>> wrapper implementations for all of the above which delegate to the
>> passed in resource provider. This makes the implementation much
>> easier.
>>
>> The decorators are ordered by their service ranking and called in this order.
>>
>> WDYT?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Carsten Ziegeler <cz...@apache.org>.
I have another use case for the decorator, it's possible to "enhance"
resources with data coming from a different location, so for example
for the file resource provider I could store metadata about a file
somewhere else and combine the information. This would also support
updating/creating the metadata.
This is also implementable by implementing a new resource provider
which combines the input of two other resource providers, but a
decorator would make this nicer/easier.
Carsten
2013/3/7 Carsten Ziegeler <cz...@apache.org>:
> Hi,
>
> as recent discussion showed, there might be use cases for a resource
> provider decorator. A decorator can be used to add functionality
> across several resource providers. E.g. this would simplify securing
> resource providers which don't support access checks ootb, like the
> file resource provider or the MongoDB resource provider.
>
> Decorating a resource provider is not as trivial as decorating a
> resource because a provider might come in different flavours =
> implement additional functionality through sub interfaces.
> So I think just having a single decorate method is too error-prone as
> the implementation would have to check whether a resource provider
> implements those interfaces and construct a corresponding resource
> provider.
>
> Therefore I propose we add a simple interface:
> public interface ResourceProviderDecorator {
>
> ResourceProvider decorate(final ResourceProvider provider);
>
> AttributableResourceProvider decorate(final
> AttributableResourceProvider provider);
>
> ModifyingResourceProvider decorate(final ModifyingResourceProvider
> provider);
>
> QueriableResourceProvider decorate(final QueriableResourceProvider
> provider);
>
> DynamicResourceProvider decorate(final DynamicResourceProvider provider);
> }
>
> which allows to decorate each separately. At the same time we add
> wrapper implementations for all of the above which delegate to the
> passed in resource provider. This makes the implementation much
> easier.
>
> The decorators are ordered by their service ranking and called in this order.
>
> WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceProviderDecorator
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 07.03.2013, at 11:40, Carsten Ziegeler <cz...@apache.org> wrote:
> Decorating a resource provider is not as trivial as decorating a
> resource because a provider might come in different flavours
Wait - I misunderstood your proposal in the other thread. I thought this would still decorate Resources, but only for a single resource provider, and not for the entire resource tree.
What I mean really sounds like a wrapping ResourceProvider to me, which would be even simpler (no additional interface), but I thought there might be little simplicity advantages with such an additional decorator, hence I thought that might be a good compromise.
Cheers,
Alex