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: [email protected] [mailto:[email protected]] On Behalf Of Ian
>> Boston
>> Sent: Friday, March 08, 2013 9:59 PM
>> To: [email protected]
>> 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 <[email protected] <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
>>> [email protected] <javascript:;>
>>>
--
Felix Meschberger | Principal Scientist | Adobe
