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 <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:;> > >
