On Monday 04 February 2002 02:03 am, Daniel Fagerstrom wrote:
<snip/>
> 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?
>
Resource based AC seems like an administrative nightmare. Bad enough to have
to specify somewhere (and hopefully in one place! - as per your suggestion
there's no way to guarantee this) exactly what users have what rights on what
resources. In fact, I forsee establishing groups that have access rights to
the resources needed for any one URI, and adding users to them, which is
essentially equivalent to assigning rights per URI.
Now, while this does demonstrate that resource based AC would be more
flexible, I can't really see it flexing outside of URI AC's domain and still
being correct. I can't say I'd see it being worth altering the underpinnings
of the engine to provide this level of AC.
Judson
> /Daniel Fagerstrom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
