Hi In the hope not to raise dust again... ResourceAccessGate could really help to harden existing Sling applications even if they use JCR only as backend. As mentioned many times before ResourceAccessGate does not interfere or cancel other ACLs like these from JCR and it is not a substitution of the access controlling in JCR or any other persistence layer with ACLs. But it could help to define things which you can't define in the exiting ACLs. Just two examples: - access only from 8am to 5pm on weekdays - lockdown: Only give access to a preview site to authenticated users (no matter what user). But the site is a public site - hardening a system
For the last point: As we have seen the last months (an Carsten mentioned it also), there are some cases where ResourceAccessGate could help to harden an otherwise vulnerable Sling system where ACLs on JCR just do not work. But I think also in case of access control, it is worse that one has to enable the flag that access control should take place on every resource provider. Normally to get high security we have to turn of controlling and not on. And last but not least: No one has to use ResourceAccessGate. But I think if someone like to use ResourceAccessGate it should be as easy and logical as possible. And that really would be without any flag to configure it. Just write an ResourceAccessGate and it works. Best regard Mike > -----Original Message----- > From: Felix Meschberger [mailto:[email protected]] > Sent: Tuesday, January 14, 2014 6:58 PM > To: [email protected] > Subject: Re: Reconsidering when to apply resource access security > > 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. > > > 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 ? > > > > > Whether we should use the gate for the feature flag implementation is a > > different thing then and can be discussed in another thread :) > > Sure thing. > > Regards > Felix > > > > > Regards > > Carsten > > > > > > 2014/1/13 Felix Meschberger <[email protected]> > > > >> -.5 > >> > >> Not exactly vetoing but: This creates and overlap in resource providers > >> which effectively do access control (such as JCR Resource Provider) and as > >> I said before: the feature flag is not a good candidate for the security > >> system. > >> > >> After all the feature flag does visibility but no access control as in > >> "can-write", "can-delete", "can-create", etc. > >> > >> Regards > >> Felix > >> > >> > >> Am 13.01.2014 um 06:24 schrieb Carsten Ziegeler <[email protected]>: > >> > >>> Hi, > >>> > >>> after long discussions we have to the compromise to tag a resource > >> provider > >>> if a (optionally) available resource access security is used for this > >>> provider. > >>> > >>> I think this was a wrong compromise with no real value - and we should > >>> remove this additional flag and simply always apply the checks. > >>> One main driver is the new feature flags implementation which requires > >> the > >>> additional checks for all providers to properly work - and it would be a > >>> maintenance nightmare to enable the flag on all providers (default is > >> off). > >>> > >>> So, if no one complains with a good reason I'll do the change > >>> > >>> Thanks > >>> Carsten > >>> -- > >>> Carsten Ziegeler > >>> [email protected] > >> > >> > > > > > > -- > > Carsten Ziegeler > > [email protected]
