Stefano Mazzocchi wrote:
> Brian Topping wrote:
<snip/>
> > What I am wondering is whether such a CMS has any business being that
> > tight with Cocoon. If not, a set of interfaces ought to be developed
> > for them to couple through, but either way is this an attractive vision?
>
> I have the perception that Cocoon might provide components for access
> control, but should not have this semantics built right into its main
> concepts (see sitemap, flowmap).
>
> Or maybe not: access control is a first-class citizen of the realm of
> publishing (both on the front and on the back).... but I have the fear
> that tighting this too much might blow Cocoon into a full CMS and I want
> to keep this decoupled: Cocoon is already big enough.
>
> I mean: we have actions, right? access control is an action, no? Cool,
> we have the ability to add access control in Cocoon.
<snip/>
So, how can access control (AC) be integrated in Cocoon? And how much
would integration of AC need to affect the current architecture?
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.
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.
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>
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. 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>
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.
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. The only concept that
corresponds to WebDAV actions is the cocoon-action request parameter
for action sets.
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.
Comment, ideas?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
