I've implemented this now with some few difference: ResourceAccessSecurity service must be registered with a context service property, allowed values are application and provider. If the property is missing or invalid, the service is ignored - no defaulting - as we have not released this stuff, I think this makes more sense. In addition for each context, only the service with the highest ranking is used.
For chaining we have the implementation using ResourceAccessGate services - these have now to be registered with a context property as well. The implementation we have, registeres two ResourceAccessSecurity services one for context application, one for the context provider and internally calls all ResourceAccessGate services with the same context. Carsten 2014/1/15 Carsten Ziegeler <[email protected]> > Ok, thanks - so if no one complains, I'll implement this by the end of the > week. > > I really would love to finally get a new Sling API release out, it has > been a long time since the last one... > > Regards > Carsten > > > 2014/1/15 Mike Müller <[email protected]> > >> 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:[email protected]] >> > Sent: Wednesday, January 15, 2014 12:43 PM >> > To: [email protected] >> > 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 <[email protected]> >> > >> > > 2014/1/14 Felix Meschberger <[email protected]> >> > > >> > >> Hi >> > >> >> > >> Am 14.01.2014 um 00:27 schrieb Carsten Ziegeler < >> [email protected]>: >> > >> >> > >> > 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 >> > [email protected] >> > > > > -- > Carsten Ziegeler > [email protected] > -- Carsten Ziegeler [email protected]
