Although this seems to be another compromise, it has advantages to the actual flag which must be set on every provider. Sorry to say it again, but no configuration would be easier and logical. The writer of the ResourceAccessGate can decide anyway on which Resource he will apply rules or not. That's one reason why the return value of the methods on ResourceAccessGate is GateResult which has three states: GRANTED, DENIED, DONTCARE. The last means that the ResourceAccessGate does not handle this resource.
So a +0.5 from my side. Which means it is better than the status quo. The implementation of ResourceAccessSecurity respects already the service ranking of the ResourceAccessGate implementations as suggested. Best regards mike > -----Original Message----- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Wednesday, January 15, 2014 12:43 PM > To: dev@sling.apache.org > Subject: Re: Reconsidering when to apply resource access security > > So to redefine my proposal, we define a service registration property > "CONTEXT" for a ResourceAccessSecurity - if not set it defaults "provider", > allowed values are "application" and "provider" - if an invalid value is > used, the service is ignore (and this is logged as error). > > All ResourceAccessSecurity services marked with context "provider" are > chained with lowest service ranking first and invoked for all resurce > providers which indicate they don't have own security checks. > All ResourceAccessSecurity services marked with context "application" are > chained with lowest service ranking first and are always invoked. > > While I don't expect to have more than a single resource access security > service for each context, chaining them makes imho sense and gives a well > defined execution order. > > WDYT? > > Carsten > > > 2014/1/15 Carsten Ziegeler <cziege...@apache.org> > > > 2014/1/14 Felix Meschberger <fmesc...@adobe.com> > > > >> Hi > >> > >> Am 14.01.2014 um 00:27 schrieb Carsten Ziegeler <cziege...@apache.org>: > >> > >> > Ok, so let's seprate the two things for the sake of th discussion - as > >> soon > >> > as someone wants to have a resource access gate applied to all resource > >> > providers (for whatever reason), this really becomes tedious, > >> especially as > >> > you have to know and configure each and every resource provider and set > >> the > >> > flag accordingly. > >> > >> No that's not the right background for the configuration flag: The > >> background was, that a ResourceResolver indicated with this flag, whether > >> it does its own access control (as JCR Resource Provider does) or does not > >> and thus would benefit from general service. > >> > >> Yes, right - and the flag defaults to "provider does own access control". > > > > > > > >> > In the last 6 months we encountered at least two use cases where it > >> would > >> > make sense to enable the gate in front of the jcr provider as there is > >> no > >> > way to cover the use cases with ACLs (I would need to dig up the > >> details) > >> > And as has been discussed at length, the gate is an additional check, so > >> > you can't make stuff visible which is not visible from the provider. > >> > >> The access gate is a general access controller. Visibility is another yet > >> overlapping problem: One part of visibility is the access right to read (or > >> list) something. Another part is an application decision to hide something > >> even though access control would grant access. > >> > >> So, we have two cases where this surfaces: Which one (apart from the > >> feature flags ?) ? Maybe we should come up with an additional model ? > >> > > > > Ok, I see your point - you're saying we need one mechanism to apply access > > control to resource provider which do not have their own access control - > > this is kind of a "low level" mechanism. > > And we have the application level which adds additional checks across the > > whole resource tree, like hiding resources etc. > > > > If we're talking about the interface, I would assume that they both like > > pretty similar - controlling visibility on the app level might be one use > > case, but preventing write access might be another one etc. > > Right now we use the ResourceAccessSecurity for the first case. > > > > What about defining a registration property for this service, something > > like "context"? By default this is "provider" and the service is applied to > > the providers indicating they need additional access control. And if its > > set to "application", the checks are applied on top at a higher level? > > > > Regards > > Carsten > > > > > > -- > Carsten Ziegeler > cziege...@apache.org
