very nice summary. thanks alex for writing this up.
kind regards
angela
On 3/6/13 12:45 PM, Alexander Klimetschek wrote:
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
