Hi Justin Carsten's original proposal introduced two ways to handle access control: ACLAwareResourceProvider and ResourceAccessController.
The ACLAwareResourceProvider would act just like JCR Resources are currently handled, i.e. with access control already enforced by the underlying storage layer. The interface would merely indicate that this ResourceProvider takes care of access control by itself (and should presumably bypass any ResourceAccessController services). ResourceAccessController would be a new concept and interface, which allows different implementations as services. A ResourceAccessController (presumably again) indicates whether access is granted or denied. The variation I propose is to drop the ACLAwareResourceProvider concept and implement a ResourceAccessController for JCR resources instead. The implementation would grant or deny access to a resource based on ACLs in Jackrabbit. So a request for /foo would hit the SlingMainServlet, then the Authenticator. Let's assume we now have a known user, we ask any ResourceAccessController services if the user is granted access. If access is denied, an appropriate response is sent (e.g. 403). If access is granted, the ResourceProviders will be asked for the resource. If the resource is unavailable, a 404 response can be sent, otherwise Sling renders the resource. I'm not using the term ACL, as the ResourceAccessController are no declarative lists of access control information. They can be implemented in java, and one possible implementation are ACLs. Does this clarify my previous comment? Regards Julian On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson <jus...@justinedelson.com> wrote: > Hi Julian, > I don't think I understand what you are suggesting here. Can you > elaborate on what the code path would be in the case, for example, of > a Bundle Resource Provider? If a bundle provides resources under, say, > /mybundle, where would the ACL live and who would be responsible for > evaluating it? > > I feel like I'm missing something obvious, so please bear with me :) > > Thanks, > Justin > > On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <jsedd...@gmail.com> wrote: >> 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 >>> >> >
