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?
> Protection of Pipelines
> ----------------------
> In Cocoon today there are some support for action based AC:
>
> <map:match pattern="**.html">
> <map:act type="db-authenticator">
> <!-- parameters -->
> <map:generate src="docs/{1}.xml"/>
> <map:transform src="stylesheets/page/simple-page2html.xsl"/>
> <map:serialize type="html"/>
> </map:act>
> <map:redirect-to uri="login"/>
> </map:match>
>
> The idea here is that one protect a pipeline, or a set of
> pipelines. IMHO this leads to mixing of concerns: in the example above
> we might want different AC for different documents in the docs
> directory. How we construct a pipeline is do not have to be related to
> who is allowed to access it. If we have N protection classes for
> documents and M ways to present the documents we will need N*M
> different pipelines in the sitemap. Furthermore if we change the
> protection classes we will have to change the sitemap.
>
> 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).
> Protection of Request URI:s
> ---------------------------
> One way to decouple pipeline construction from AC is to describe what
> URI:s a certain user (principal) is allowed to access (and possibly in
> what way), in a separate document. For this scenario the access right
> are checked before the rest of the sitemap is allowed to be
> accessed. This could be done like this, e.g.:
>
> <map:pipeline>
> <map:act type="deny-access" src="AC.xml">
> <map:redirect-to uri="login"/>
> </map:act>
>
> <!-- Rules for actually doing something -->
>
> </map:pipeline>
This is how the Wyona folks implemented this.
> There should also be utility functions in e.g. XSP for asking about if
> an URI is accessible for the current user. This could be used to
> choose the rendering scheme for links dependent on if they are
> accessible or not.
>
> 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
:)
> Here I belive that
> it is a god idea to use the concepts from AC in webdav (see
> www.webdav.org/acl):
>
> * It is designed for AC for web resources.
> * It is standardized.
> * There are (hopefully reusable) implementations (e.g. Slide).
> * There are standardized http methods for asking a server about AC.
>
> Here is an example of AC configuration in Slide (I removed some parts
> and attributes that are of more technical nature or not relevant for
> our discussion).
>
> <objectnode uri="/">
> <permission action="/actions" subject="/users/root"/>
> <permission action="/actions/read" subject="/users"
> inheritable="false"/>
>
> <objectnode uri="/users">
> <permission action="/actions" subject="/users/guest"
> inheritable="true" negative="true"/>
> <permission action="/actions/read" subject="/users"
> inheritable="false"/>
>
> <objectnode uri="/files">
> <permission action="/actions/manage" subject="/users/john"/>
> <permission action="/actions/write" subject="+/users/groupA"/>
> <permission action="/actions/read" subject="nobody"/>
> </objectnode>
> </objectnode>
hmmmm, can't say I like this...
> In webDAV ACL the principals, actions and resources form hierarchies
> that are denoted by URI:s. For Cocoon use objectnode/@uri could
> correspond to request URI:s. The first permission rule e.g., says that
> principals who's id starts with /users/root are allowed to perform all
> actions (starting with /action) on all resources (starting with
> /). See the Slide documentation for more details.
ok, will do.
> 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.
HTTP actions provide indication on the 'behavior' expected on that URI
(are much more similar to 'views' in this realm) while Cocoon actions
are side logic that doesn't impact on the production pipeline directly.
> Access control for request URI:s could be implemented (by using an
> external AC system like e.g. Slide) without affecting the current
> contracts in Cocoon. IMO, AC based on request URI:s offers a much
> better SoC than AC based on protection of pipelines, but it still has
> the drawback that it doesn't protect resources.
>
> Protection of resources
> -----------------------
> So what would it mean to protect the resources that are used to
> fulfill a request to Cocoon? Consider the following pipeline:
>
> <map:match pattern="foo.html">
> <map:generate src="foo.xml"/>
> <map:transform type="sql">
> <map:parameter name="use-connection" value="bar"/>
> </map:transform>
> <map:transform src="table2html.xsl"/>
> <map:serialize/>
> </map:match>
>
> If we had a resource based AC system, then to be allowed to access
> foo.html, the user would be required to have read access to foo.xml,
> and execute access to table2html.xsl, what access rigths that are
> needed for the access of the DB bar is harder to know, as it would
> require an analysis of the query. Anyhow, the mechanism is that the
> user is allowed to perform an operation on a resource if the user has
> the required access rights for all resources that are needed to
> compose the pipeline. All components with access restriction must thus
> be able to tell what is allowed, they must implement a AC interface,
> e.g.:
>
> interface Accessible {
> boolean hasPermission(Resource object, Principal subject, Action
> action);
> }
>
> And composed component must know what kind of actions that are needed
> for its parts. This gives a hint about the distribution of
> responsibility for AC: non-composed component should ask an underlying
> CMS about AC, and composed component must be able to combine access
> rights.
>
> 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? how about
aggregation? how about selectors?
I still think that you don't need this level of access granularity and
that, if given, might be more usability trouble for the enduser than it
is for you to design the sitemap.
But this is just my personal opinion, anyway.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
