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 <fmesc...@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 >>> cziege...@apache.org <javascript:;> >>> -- Felix Meschberger | Principal Scientist | Adobe