2011/11/12 Julian Sedding <[email protected]>: > 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).
Yes, sounds like an interesting idea - it would also solve the problem to distinguish between a none existing resource and denied access in the JCR case. Regards Carsten > > Thoughts? > > Regards > Julian > > > On Sat, Nov 12, 2011 at 4:29 AM, Carsten Ziegeler <[email protected]> > 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 >> [email protected] >> > -- Carsten Ziegeler [email protected]
