cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Judson Lester <jud...@irev2.com>
Subject Re: [RT] Access Control (was [RT] Cocoon as OS)
Date Mon, 04 Feb 2002 19:34:09 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message