Re: [RT] Access Control in ResourceProviders
Hi, Am 13.03.2013 um 12:14 schrieb Alexander Klimetschek: > On 13.03.2013, at 10:38, Felix Meschberger 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
On 13.03.2013, at 10:38, Felix Meschberger 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
On Wed, Mar 13, 2013 at 10:38 AM, Felix Meschberger 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
Hi,
Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
> On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger
> 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
On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger 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
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
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
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
> From: Felix Meschberger [mailto:fmesc...@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
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: ianbos...@gmail.com [mailto:ianbos...@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 >: >>>> 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 >>> cziege...@apache.org >>> -- Felix Meschberger | Principal Scientist | Adobe
Re: [RT] Access Control in ResourceProviders
Hi, On Mon, Mar 11, 2013 at 11:36 AM, Mike Müller 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
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: ianbos...@gmail.com [mailto:ianbos...@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 >: > > > 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 > > cziege...@apache.org > >
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 >: > > 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 > cziege...@apache.org >
Re: [RT] Access Control in ResourceProviders
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 : > 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 cziege...@apache.org
