hi carsten well... my concerns with respect to having access control enforced on different layers hasn't changed... but i don't know if it's worth repeating the arguments again. IMHO this is not a security feature but will instead harm proper and secure setup in our products at adobe. it will not only make it harder to understand why someone has or hasn't access to some resource but will most like generate a false sense of security because you will have a relaxed access control on the deepest level... but that has all been said before.
since i am not a sling developer, you may consider may concerns nonbinding. but i am definitely opposed to have that feature enabled by default in our product. kind regards angela On 15/01/14 17:16, "Carsten Ziegeler" <[email protected]> wrote: >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]
