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]
