Stefano Mazzocchi wrote: > Daniel Fagerstrom wrote: > > So, how can access control (AC) be integrated in Cocoon? And how much > > would integration of AC need to affect the current architecture? > > These are good questions. I don't have solid answers, but some comments > to share hoping to sparkle discussion in the right direction. > > > I think there are three main points for AC in Cocoon: > > > > 1. Protection of pipelines. > > 2. Protection of request URI:s. > > 3. Protection of resources (content and components) that are used to > > fulfill a request. > > Hmmm, ok for the first two, but I don't see the need for the third one. > I mean: once you have your URIs and your URI protection, why would you > need any more granularity?
Maybe I should have stated my asumptions, (instead of just having them in my mind while writing ;) ): 1. In many applications it is your DB content or your documents that is the natural unit of protectection, rahter than their various combinations and presentation. 2. To be able to handle protection of your content, a CMS would be nice to have. 3. If we let a CMS handle the content that Cocoon gives web access to I would rather like to know before I compose and start a pipeline, if I will be allowed to excecute all its part, than getting an access violation exception during its excecution. My conclusion is that in the context of the above assumptions is that: Cocoon should be able to derive the access rights for a request URI from access rights of its participating components. This is analouge to how cocoon derives if a pipeline is cachable from its components cachability. <snip/> > > Pipeline based AC is useful (and maybe the only realistic alternative) > > for operations like updates in DB, but does not seem to scale well. > > Granted but this is by design: pipelines are 'groups of URIs that happen > to share concerns'... so applying attributes to pipelines (like AC for > example) is a highly granular operation, but rightly so (IMO, anyway). hmm ... seem reasonable, maybe I should wait and see if it becomes a scalability problem in practice, before trying to find a cure. Maybe it is more about distributing administration resposibilties. <snip/> > > We need a format for describing the access rights. > > Yes. I can't remember what they used... hmmm, checkout www.wyona.org > yourself and see how they did it (now their XPS, eXtensible Publishing > System, is entirely based on Cocoon... with the (paid) help of Giacomo > :) I will take a look at it. <snip/> > > In WebDAV action classes corresponds to HTTP methods, like GET, PUT, > > DELETE, etc. What they correspond to in Cocoon is not obvious, for > > ordinary webapps only GET and POST are used and Cocoon does not care > > much about what HTTP method that is used. > > Nor should. A WebDAV application (like Slide) is something that should > work on Top of cocoon... cocoon (just like a servlet engine) should not > deal with the different HTTP actions which are just application stuff. > > (this doesn't meean that we can't have a HTTPActionSelector as a > component... this is something I have in my todo list since last year!) > > > The only concept that > > corresponds to WebDAV actions is the cocoon-action request parameter > > for action sets. > > Wrong! These are totally different things and should not be mixed just > because they happen to share the same name. Ok I agree, what I mean is that you might want to allow some values for a cocoon-action for a certain user, but not others. <snip/> > > To conclude: I belive that a request URI based AC system have clear > > advantages compared to pipeline based AC, and that it could be added > > to Cocoon without effecting the contracts at all. I also think that > > the "correct" way of handling security is a resource based system, and > > that a such would need to affect the inner workings of Cocoon. > > Hmmm, interesting vision. > > Just one question: what about errors? how do you handle them? What errors :) Maybe I missed something, the only new category of errors should be access violation errors, it might be practical to trap those in a special error handling rule so that the user e.g. can be redirected to a login page. > how about aggregation? how about selectors? The main idea is that you only can access an request URI if you are allowed to access all components that are needed to build its pipeline, so for agregation you just check the request URI:s for the parts. For selection it is more complicated, the selection of components for the pipeline can depend on the result of actions that have sideeffect. I guess that a general requirement is that the sitemap is so declarative that it is possible to draw any conclusion about its runtime behaviour, (conditioned on request parameters) from a static analysis of it. /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
