> I share the performance concern if a jcr node has to be checked twice > as this would double the repository access per request. > > In general I think we can go with this (for reading): > 1. ResourceProvider delivers resource and maybe does already the ACL > check (like in the JCR case) > 2. ResourceAccessController do additional checks > > This is a general approach, avoids duplicate checks and ensures that > it's not possible to circumvent JCR ACLs.
+1 Step 2) can be skipped, if no resource is returned. And in addition this gives us the possibility to pass the found resource to the ResourceAccessController. That enables a specific ResourceAccessController to make the decision to allow or deny access to this ressource dependent on the data of the resource and not only the path of the resource. best regards mike > > As mentioned, the only potential drawback is that for the same path > different users might end up with different resources. But I think we > can live with that. > > Regards > Carsten > > 2011/11/22 Mike Müller <mike...@mysign.ch>: > > Okay, I might be a little bit late in the discussion... > > We're at MySign thought about such a access control layer in Sling a few > > months ago. Mainly because we do have different resource providers > > without the possibility of ACLs and also because some access rules > > can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource). > > We do have such an access layer in our legacy framework and there > > we also have the possibility to define the access rules declarative (like > > ACLs) but also by somtehing like the proposed ResourceAccessController > > services. > > > > I do share Justins fear, that we get poor performance if we do have to > > call the JCR provider twice to once get to know if the user has access and > > once to get the resource. But maybe the JCR resource provider can cache > > the resource from the first call and the performance ist fine. > > I think we should not design a general architecture for access controlling > > an make the JCR a special case. I would prefer a "clean" design with only > > one service interface for access controlling (without exceptions). > > The approach where the ResourceProvider implements it's own access > > control mechanism avoids the possibility for a special > > ResourceAccessController > > to overwrite some access roles (like the example above with access > > between 8.00 and 17.00). Plus, it would be less understandable than the > > clean approach with just one entry point where access controlling is > > taking place. > > > > What I missed in the discussion so far is, that the proposed mechanisms > > are only usable for read. I think a general access controller mechanism in > > Sling should provide access controlling for read, write, modify and delete. > > With such an architecture it would be much easier to control security > > aspects > > of the application. > > > > best regards > > mike > > > > > >> -----Original Message----- > >> From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of > Justin > >> Edelson > >> Sent: Tuesday, November 15, 2011 5:24 AM > >> To: dev@sling.apache.org > >> Subject: Re: [RT] Improving access control > >> > >> Thanks for the clarification Julian. This makes more sense. I have two > >> concerns with the variant you're describing: > >> > >> 1) It does not provide a way for ResourceProvider implementers to > >> provide their own access control mechanism, which is one thing I > >> really liked in Carsten's original proposal. > >> 2) In the case of the JCR ResourceProvider, it seems likely to lead to > >> poor performance because the access control rules in the repository > >> will be evaluated twice. > >> > >> Justin > >> > >> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding <jsedd...@gmail.com> wrote: > >> > 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 > >> >>>> > >> >>> > >> >> > >> > > > > > > > -- > Carsten Ziegeler > cziege...@apache.org
