Agree. The core problem of the access gate is that it applies *on top of* all the resource providers, for the entire "virtual" resource tree created by the resource resolver (at least that's how I understand the current patch).
That will seem like an easy way for devs to hook in some ad-hoc security features - which of course will be ill-fated (ad-hoc always will be in the context of security ;-)), apart from the multiple points of security features (up in sling vs. down in JCR or DB). Thus we should not give devs such a dangerous tool in their hands. As a general rule, I would say that the security layer has to be done by each ResourceProvider themselves or come with the backend they wrap, such as JCR. If it comes with the backend, you should really not do security on top of it again. If yes, it should be confined to that ResourceProvider, since you don't know how other resource providers work and what security features they bring to the table, which might not mix well with what you are doing here. Using the resource decorator is IMO not optimal, since it can be used across all resource providers as well, but it seems you'd use the decorator for specific resources anyway and thus it might be a good compromise for this dicussion. OTOH: how difficult would it be to write a resource provider that wraps another one? AFAICS, this would require zero additions to Sling itself. Cheers, Alex On 06.03.2013, at 12:17, Lars Krapf <[email protected]> wrote: > Hello > > Please accept my 2.3 cents to this discussion: > > I really agree with Angela and Bertrand on this one. > Something that could be called AccessGate is clearly a security > mechanism, and should thus be designed with single point of access in > mind. > Having ACL evaluations scattered among the code-base makes it > harder to configure (and thus easier to make mistakes), and increases > the overall attack surface. To me Sling is not the right layer for > such a feature, IMHO it should be implemented on repository level by > extending Jackrabbit's ACL evaluation if time-based access control > is really needed. > This is also an example of how this feature would weaken > security. In order to allow access to a resource within a certain > time-frame, you will have to open access completely on repository > level, so the whole access control would depend on the Sling layer, > and we introduce a bunch of new attack possibilities, and > unnecessarily complicate the threat model. > > I think a ResourceResolverDecorator might be useful in some cases. > But having access control features in sling core just feels wrong to me. > > Best greetings > Lars > > > On 03/06/2013 11:23 AM, Bertrand Delacretaz wrote: >> On Wed, Mar 6, 2013 at 11:03 AM, Carsten Ziegeler <[email protected]> >> wrote: >>> ...this would mean, we trust people implementing >>> ResourceResolverDecorator, but we don't trust them implementing >>> ResourceAccessGates.... >> >> I see your point...I guess it's very subjective factors here, I prefer >> ResourceResolverDecorator to ResourceAccessGate although both can >> potentially be abused (like many of our extension points). >> >> Let's see what others think. >> >> -Bertrand >> >
