Hi Carsten Interesting idea. Having access control handled by services allows implementing arbitrary access control logic, which I would welcome. In my experience, it's often difficult to express access control logic in a declarative manner.
I think we could further simplify the approach you describe. Leave the ResourceProvider interface as it is and don't introduce an ACLAwareResourceProvider interface. Instead have the JCR ResourceProvider also implement ResourceAccessController. This simplifies the design, while allowing to expose the same logic. Additionally, it adds the possibility to layer additional access control on top of Jackrabbit ACLs, thus allowing to combine the best of both worlds (access control logic implemented in java + Jackrabbit's declarative ACLs). Thoughts? Regards Julian On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > We support different resource providers, JCR, bundle, file etc. but so > far only JCR implements access control based on the provided user. > This leads to problems when resources are provided for example from a > bundle or the file system as there is either no real ACL check is in > place. > I think we should change that! > > First, if a resource provider supports ACL checks like JCR it just > should declare this by using a new interface ACLAwareResourceProvider > (or any better name) which is just a marker interface. > If a resource is provided by provider which does not declare this, > well send the resource through a new service ResourceAccessControler > (or a better name) which either allows or denies the resource. We > could allow here several services which are asked in the order of > their service ranking until one of them provides a definite answer. If > none provides an answer, the resource is served - for compatibility. > > With this we should be able to easily hook on access control for such > providers not directly supporting it while staying compatible. > > Now, however there is a problem with the whole apprach - if a provider > is an ACLAwareResourceProvider we need to know internally if the > resource exists but the user is not allowed to access it, or if the > resource does not exist. Otherwise we potentially end up with a > resource at /somepath provided by provider A for user U1, and provided > by provider B for user U2 as user U2 is not allowed to access this > resource in provider A. > > WDYT? > > Regads > Carsten > -- > Carsten Ziegeler > cziege...@apache.org >
