You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/03/08 12:43:49 UTC
[RT] Access Control in ResourceProviders
Hi all
There have been a number of threads and proposal flying around recently in an attempt to make the Resource API more secure: It started with Mike's ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
I would like to promote a third strategy:
* ResourceProviders are expected to implement access control at their own level. They do so in their own implementation or they leverage access control support of the underlying data store (as the JCR ResourceProvider does).
* The ResourceAccessGate is a helper service for ResourceProviders to implement access control if they wish to do so.
WDYT ?
Regards
Felix
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Access Control in ResourceProviders
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 13, 2013 at 10:38 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
>>...adapting the JCR permissions model to Sling
>> resources would be my favorite way by far - that model is known to
>> work and we are familiar with it, no need to reinvent too many wheels.
>
> If we can implement Mike's new service ontop of JCR, I think we are fine, right ? I just
> don't want to nail non-JCR ResourceProviders onto JCR directly. That would be
> counter-productive....
Absolutely agree - what I mean is that if we need to design an access
control mechanism for non-JCR resource providers, let's reuse the JCR
permissions *model* as much as possible. Without having dependencies
to JCR, but just reusing those ideas that are known to work in there,
and should be familiar to Sling developers who use JCR.
-Bertrand
Re: [RT] Access Control in ResourceProviders
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 13.03.2013 um 12:14 schrieb Alexander Klimetschek:
> On 13.03.2013, at 10:38, Felix Meschberger <fm...@adobe.com> wrote:
>
>> I think that's start of my thread: Don't use ResourceProviderDecortator or some other non-mandatory thing to implement access control. Access control should be intrinsic to the ResourceProvider and the ResourceProvider should either leverage the underlying store (as the JCR ResourceProvider) or use a central service which Mike is now going after.
>
> And if you have an existing ResourceProvider such as the file system one that you want to enhance with an ACL mechanism, you:
> - build a new resource provider, e.g. AclFSResourceProvider
> - that wraps the existing one (fs provider)
> - uses the new separate acl service ResourceAccessSecurity
>
> That should work, right? A wrapper can do the ACL checks and decide whether to return something or null, or wrap modifieable resources with an ACL check or not.
That's one option (though insecure of some sort). For the concrete case of the FSResourceProvider, Mike's idea is to add support for the acl service into the base FSResourceProvider -- maybe we can add configuration to require or not ACL support.
Regards
Felix
>
> Cheers,
> Alex
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Access Control in ResourceProviders
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 13.03.2013, at 10:38, Felix Meschberger <fm...@adobe.com> wrote:
> I think that's start of my thread: Don't use ResourceProviderDecortator or some other non-mandatory thing to implement access control. Access control should be intrinsic to the ResourceProvider and the ResourceProvider should either leverage the underlying store (as the JCR ResourceProvider) or use a central service which Mike is now going after.
And if you have an existing ResourceProvider such as the file system one that you want to enhance with an ACL mechanism, you:
- build a new resource provider, e.g. AclFSResourceProvider
- that wraps the existing one (fs provider)
- uses the new separate acl service ResourceAccessSecurity
That should work, right? A wrapper can do the ACL checks and decide whether to return something or null, or wrap modifieable resources with an ACL check or not.
Cheers,
Alex
Re: [RT] Access Control in ResourceProviders
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
> On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger <fm...@adobe.com> wrote:
>> ...Actually: It turns out that doing a ResourceProviderDecorator right is quite complex given
>> the potential combinations of ResourceProvider extensions that might have to be captured.
>> For now I would even go as far as to drop the ResourceProviderDecorator idea alltogether....
>
> Interesting...I'm totally confused now, is that conclusion based on
> on-list discussions that I missed?
I think that's start of my thread: Don't use ResourceProviderDecortator or some other non-mandatory thing to implement access control. Access control should be intrinsic to the ResourceProvider and the ResourceProvider should either leverage the underlying store (as the JCR ResourceProvider) or use a central service which Mike is now going after.
>
> I guess what we need is for whoever wants to work on this ("this"
> being access control for non-JCR resource providers, which is IMO the
> core topic here) to start by writing down use cases on which we can
> agree, and we can then look at how to implement them.
>
> As I said before, adapting the JCR permissions model to Sling
> resources would be my favorite way by far - that model is known to
> work and we are familiar with it, no need to reinvent too many wheels.
If we can implement Mike's new service ontop of JCR, I think we are fine, right ? I just don't want to nail non-JCR ResourceProviders onto JCR directly. That would be counter-productive.
Regards
Felix
Re: [RT] Access Control in ResourceProviders
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...Actually: It turns out that doing a ResourceProviderDecorator right is quite complex given
> the potential combinations of ResourceProvider extensions that might have to be captured.
> For now I would even go as far as to drop the ResourceProviderDecorator idea alltogether....
Interesting...I'm totally confused now, is that conclusion based on
on-list discussions that I missed?
I guess what we need is for whoever wants to work on this ("this"
being access control for non-JCR resource providers, which is IMO the
core topic here) to start by writing down use cases on which we can
agree, and we can then look at how to implement them.
As I said before, adapting the JCR permissions model to Sling
resources would be my favorite way by far - that model is known to
work and we are familiar with it, no need to reinvent too many wheels.
-Bertrand
Re: [RT] Access Control in ResourceProviders
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 12.03.2013 um 15:40 schrieb Angela Schreiber:
> hi carsten
>
>> just to clarify, the ResourceProviderDecorator is not a proposal for
>> security - it's a proposal for extensibility.
>
> i tend to disagree. as lars already explained in this thread before
> you can't have extensibility when it comes to access control and
> permissions without messing with the internal mechanism.
>
> imo claiming that this has nothing to do with security is not
> correct and misleading.
That's not what Carsten tried to say: Point is that the ResourceProviderDecorator can be used for any extensibility. But it is *not* the means to implement security. We are on the same page ;-)
Actually: It turns out that doing a ResourceProviderDecorator right is quite complex given the potential combinations of ResourceProvider extensions that might have to be captured. For now I would even go as far as to drop the ResourceProviderDecorator idea alltogether.
For completeness sake: The current ResourceProviderDecorator has another flaw in that it is not provided with the ResourceProvider root registrations ...
Regards
Felix
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Access Control in ResourceProviders
Posted by Angela Schreiber <an...@adobe.com>.
hi carsten
> just to clarify, the ResourceProviderDecorator is not a proposal for
> security - it's a proposal for extensibility.
i tend to disagree. as lars already explained in this thread before
you can't have extensibility when it comes to access control and
permissions without messing with the internal mechanism.
imo claiming that this has nothing to do with security is not
correct and misleading.
kind regards
angela
RE: [RT] Access Control in ResourceProviders
Posted by Mike Müller <mi...@mysign.ch>.
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> > Okay, as far as I understand we've got the consensus of separating my access gate
> > proposal from the Sling API. We should have something like a
> ResourceAccessSecurity
> > service in a extension bundle,
>
> I think we can keep the basic singleton service (you call it ResourceAccessSecurity
> now, right?) in the API and document it like this:
>
> * Expected to only be implemented once in the framework/application
> (much like the OSGi LogService or Configuration Admin Service)
> * ResourceProvider implementations are encouraged (or stronger)
> to use this service for access control unless the underlying
> storage already has it.
>
> > I think we don't loose the goal of bringing Sling
> > forward to a frontend of resources from different providers than JCR without
> > any security built in (like MongoDB, file provider, bundle provider etc.) with this
> > new setup. If we go down this road I propose the following:
> >
> > Making a new bundle (extension) with a new service called ResourceAccessSecurity.
>
> +1
>
> > Taking the ResourceAccessGate interface out of the Sling API but keeping it as
> > a "access rule feeder" interface for the new ResourceAccessSecurity service.
>
> So the actual ResourceAccessSecurity service implementation bundle will define its own
> extensibility model, right ?
Yes, that's right, through the ResourceAccessGate interface.
Best regards
mike
RE: [RT] Access Control in ResourceProviders
Posted by Mike Müller <mi...@mysign.ch>.
Hi
To be sure (and save some time coding ;-) ), I sum up our discussion:
We can keep the basic singleton service (ResourceAccessSecurity) in the API
and document it like this:
* Expected to only be implemented once in the framework/application
(much like the OSGi LogService or Configuration Admin Service)
* ResourceProvider implementations are encouraged (or stronger)
to use this service for access control unless the underlying
storage already has it.
We implement the ResourceAccessSecurity service in a extension bundle.
There will be only one implementation of this service (singleton).
The implementation of ResourceAccessSecurity will use the proposed
ResourceAccessGate for it's own extensability.
We implement the use of the ResourceAccessSecurity service in FsResourceProvider
And BundleResourceProvider.
If that is okay I will come up with some new code.
Best regards
mike
Re: [RT] Access Control in ResourceProviders
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 11.03.2013 um 11:36 schrieb Mike Müller:
> Hi
>
> Okay, as far as I understand we've got the consensus of separating my access gate
> proposal from the Sling API. We should have something like a ResourceAccessSecurity
> service in a extension bundle,
I think we can keep the basic singleton service (you call it ResourceAccessSecurity now, right?) in the API and document it like this:
* Expected to only be implemented once in the framework/application
(much like the OSGi LogService or Configuration Admin Service)
* ResourceProvider implementations are encouraged (or stronger)
to use this service for access control unless the underlying
storage already has it.
> I think we don't loose the goal of bringing Sling
> forward to a frontend of resources from different providers than JCR without
> any security built in (like MongoDB, file provider, bundle provider etc.) with this
> new setup. If we go down this road I propose the following:
>
> Making a new bundle (extension) with a new service called ResourceAccessSecurity.
+1
> Taking the ResourceAccessGate interface out of the Sling API but keeping it as
> a "access rule feeder" interface for the new ResourceAccessSecurity service.
So the actual ResourceAccessSecurity service implementation bundle will define its own extensibility model, right ?
>
> I think this is a good compromise, but we should then integrate the use of
> this service in existing providers without any ACLs like FsResourceProvider and
> BundleResourceProvider.
>
> WDYT?
Yes, I think this is what I was going after -- and using this new service in the FsResourceProvider and the BundleResourceProvider would just be consequential.
Regards
Felix
>
> best regards
> Mike
>
>
>
>> -----Original Message-----
>> From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian
>> Boston
>> Sent: Friday, March 08, 2013 9:59 PM
>> To: dev@sling.apache.org
>> Subject: Re: [RT] Access Control in ResourceProviders
>>
>> Hi,
>> Should the ResourceAccessGate be a service or a utility helper class the
>> ResourceProvider can instance and configure? I can imagine generalising
>> path+principal+permission assertions as utility helper class leaving the
>> ResourceProvider with to implement an interface to provided data to feed
>> that class.
>>
>> Either way, I think Felix's proposal makes sense, but as Carsten says we
>> need to hear from Mike.
>>
>> Ian
>>
>>
>> On Friday, March 8, 2013, Carsten Ziegeler wrote:
>>
>>> Hi,
>>>
>>> just to clarify, the ResourceProviderDecorator is not a proposal for
>>> security - it's a proposal for extensibility. Feature's like the
>>> ResourceAccessGate can be implemented with them - but I think the
>>> decorator makes sense regardless of that.
>>>
>>> While I agree that resource providers should implement access control
>>> on their own (or use the one from the underlying storage), I'm not
>>> sure if that is feasible or efficient in all cases. If we go down this
>>> road, we should add the usage of such a service to all our resource
>>> providers (file, servlet, mongo) except jcr.
>>> And if we would do this, we would need an additional service which
>>> keeps track of all ResourceAccessGate's and has all the logic to
>>> handle them implemented and can easily be used by a provider - so
>>> basically most of the stuff from Mike which is now in the resource
>>> resolver.
>>>
>>> I'm not against this, but I don't have a strong perference either - so
>>> let's hear from Mike what he thinks :)
>>>
>>> Carsten
>>>
>>> 2013/3/8 Felix Meschberger <fmeschbe@adobe.com <javascript:;>>:
>>>> Hi all
>>>>
>>>> There have been a number of threads and proposal flying around recently
>>> in an attempt to make the Resource API more secure: It started with Mike's
>>> ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
>>>>
>>>> I would like to promote a third strategy:
>>>>
>>>> * ResourceProviders are expected to implement access control at their
>>> own level. They do so in their own implementation or they leverage access
>>> control support of the underlying data store (as the JCR ResourceProvider
>>> does).
>>>>
>>>> * The ResourceAccessGate is a helper service for ResourceProviders to
>>> implement access control if they wish to do so.
>>>>
>>>> WDYT ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> --
>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org <javascript:;>
>>>
--
Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Access Control in ResourceProviders
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Mar 11, 2013 at 11:36 AM, Mike Müller <mi...@mysign.ch> wrote:
> ...If we go down this road I propose the following:
>
> Making a new bundle (extension) with a new service called ResourceAccessSecurity.
> Taking the ResourceAccessGate interface out of the Sling API but keeping it as
> a "access rule feeder" interface for the new ResourceAccessSecurity service....
Not sure what this means exactly, the best is probably for you to
supply a prototype in code.
(and revert the SLING-2698 changes I assume)
-Bertrand
RE: [RT] Access Control in ResourceProviders
Posted by Mike Müller <mi...@mysign.ch>.
Hi
Okay, as far as I understand we've got the consensus of separating my access gate
proposal from the Sling API. We should have something like a ResourceAccessSecurity
service in a extension bundle, I think we don't loose the goal of bringing Sling
forward to a frontend of resources from different providers than JCR without
any security built in (like MongoDB, file provider, bundle provider etc.) with this
new setup. If we go down this road I propose the following:
Making a new bundle (extension) with a new service called ResourceAccessSecurity.
Taking the ResourceAccessGate interface out of the Sling API but keeping it as
a "access rule feeder" interface for the new ResourceAccessSecurity service.
I think this is a good compromise, but we should then integrate the use of
this service in existing providers without any ACLs like FsResourceProvider and
BundleResourceProvider.
WDYT?
best regards
Mike
> -----Original Message-----
> From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian
> Boston
> Sent: Friday, March 08, 2013 9:59 PM
> To: dev@sling.apache.org
> Subject: Re: [RT] Access Control in ResourceProviders
>
> Hi,
> Should the ResourceAccessGate be a service or a utility helper class the
> ResourceProvider can instance and configure? I can imagine generalising
> path+principal+permission assertions as utility helper class leaving the
> ResourceProvider with to implement an interface to provided data to feed
> that class.
>
> Either way, I think Felix's proposal makes sense, but as Carsten says we
> need to hear from Mike.
>
> Ian
>
>
> On Friday, March 8, 2013, Carsten Ziegeler wrote:
>
> > Hi,
> >
> > just to clarify, the ResourceProviderDecorator is not a proposal for
> > security - it's a proposal for extensibility. Feature's like the
> > ResourceAccessGate can be implemented with them - but I think the
> > decorator makes sense regardless of that.
> >
> > While I agree that resource providers should implement access control
> > on their own (or use the one from the underlying storage), I'm not
> > sure if that is feasible or efficient in all cases. If we go down this
> > road, we should add the usage of such a service to all our resource
> > providers (file, servlet, mongo) except jcr.
> > And if we would do this, we would need an additional service which
> > keeps track of all ResourceAccessGate's and has all the logic to
> > handle them implemented and can easily be used by a provider - so
> > basically most of the stuff from Mike which is now in the resource
> > resolver.
> >
> > I'm not against this, but I don't have a strong perference either - so
> > let's hear from Mike what he thinks :)
> >
> > Carsten
> >
> > 2013/3/8 Felix Meschberger <fmeschbe@adobe.com <javascript:;>>:
> > > Hi all
> > >
> > > There have been a number of threads and proposal flying around recently
> > in an attempt to make the Resource API more secure: It started with Mike's
> > ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
> > >
> > > I would like to promote a third strategy:
> > >
> > > * ResourceProviders are expected to implement access control at their
> > own level. They do so in their own implementation or they leverage access
> > control support of the underlying data store (as the JCR ResourceProvider
> > does).
> > >
> > > * The ResourceAccessGate is a helper service for ResourceProviders to
> > implement access control if they wish to do so.
> > >
> > > WDYT ?
> > >
> > > Regards
> > > Felix
> > >
> > > --
> > > Felix Meschberger | Principal Scientist | Adobe
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org <javascript:;>
> >
Re: [RT] Access Control in ResourceProviders
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Should the ResourceAccessGate be a service or a utility helper class the
ResourceProvider can instance and configure? I can imagine generalising
path+principal+permission assertions as utility helper class leaving the
ResourceProvider with to implement an interface to provided data to feed
that class.
Either way, I think Felix's proposal makes sense, but as Carsten says we
need to hear from Mike.
Ian
On Friday, March 8, 2013, Carsten Ziegeler wrote:
> Hi,
>
> just to clarify, the ResourceProviderDecorator is not a proposal for
> security - it's a proposal for extensibility. Feature's like the
> ResourceAccessGate can be implemented with them - but I think the
> decorator makes sense regardless of that.
>
> While I agree that resource providers should implement access control
> on their own (or use the one from the underlying storage), I'm not
> sure if that is feasible or efficient in all cases. If we go down this
> road, we should add the usage of such a service to all our resource
> providers (file, servlet, mongo) except jcr.
> And if we would do this, we would need an additional service which
> keeps track of all ResourceAccessGate's and has all the logic to
> handle them implemented and can easily be used by a provider - so
> basically most of the stuff from Mike which is now in the resource
> resolver.
>
> I'm not against this, but I don't have a strong perference either - so
> let's hear from Mike what he thinks :)
>
> Carsten
>
> 2013/3/8 Felix Meschberger <fmeschbe@adobe.com <javascript:;>>:
> > Hi all
> >
> > There have been a number of threads and proposal flying around recently
> in an attempt to make the Resource API more secure: It started with Mike's
> ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
> >
> > I would like to promote a third strategy:
> >
> > * ResourceProviders are expected to implement access control at their
> own level. They do so in their own implementation or they leverage access
> control support of the underlying data store (as the JCR ResourceProvider
> does).
> >
> > * The ResourceAccessGate is a helper service for ResourceProviders to
> implement access control if they wish to do so.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> > --
> > Felix Meschberger | Principal Scientist | Adobe
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org <javascript:;>
>
Re: [RT] Access Control in ResourceProviders
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
just to clarify, the ResourceProviderDecorator is not a proposal for
security - it's a proposal for extensibility. Feature's like the
ResourceAccessGate can be implemented with them - but I think the
decorator makes sense regardless of that.
While I agree that resource providers should implement access control
on their own (or use the one from the underlying storage), I'm not
sure if that is feasible or efficient in all cases. If we go down this
road, we should add the usage of such a service to all our resource
providers (file, servlet, mongo) except jcr.
And if we would do this, we would need an additional service which
keeps track of all ResourceAccessGate's and has all the logic to
handle them implemented and can easily be used by a provider - so
basically most of the stuff from Mike which is now in the resource
resolver.
I'm not against this, but I don't have a strong perference either - so
let's hear from Mike what he thinks :)
Carsten
2013/3/8 Felix Meschberger <fm...@adobe.com>:
> Hi all
>
> There have been a number of threads and proposal flying around recently in an attempt to make the Resource API more secure: It started with Mike's ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
>
> I would like to promote a third strategy:
>
> * ResourceProviders are expected to implement access control at their own level. They do so in their own implementation or they leverage access control support of the underlying data store (as the JCR ResourceProvider does).
>
> * The ResourceAccessGate is a helper service for ResourceProviders to implement access control if they wish to do so.
>
> WDYT ?
>
> Regards
> Felix
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org