You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@swipnet.se> on 2002/02/04 09:03:39 UTC
[RT] Access Control (was [RT] Cocoon as OS)
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Greg Weinger <gw...@itmedicine.net>.
> > That's precisely what I'd like to avoid : write an authenticator for
> > each and every servlet engine my app has to run on, including those
I
> > know nothing about :(
> >
> > This is IMHO a major problem in J2EE. Could JAAS help here ?
>
> IIRC, JAAS know is part of the J2EE. Am I right? Then yes, it must be
> the missing link here.
Aha, it's in JSDK 1.4, and that looks like the abstraction layer to AC I
was looking for. Still not sure how it works exactly, and if it's
straightforward enough to obviate the need for some kind of AC in
Cocoon. I've got some reading to do . . .
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Vadim Gritsenko wrote:
>
> >>But the servlet spec doesn't allow a servlet to set the user
> >>credential in the container.
> >>
> >
> >It will be set for you by the container.
> >
>
> There'a misunderstanding here : if authentication is performed by an
> Action,
I never said that. If by an action - see below - there is nothing in the
spec.
> the container has already given us a request, and we cannot give
> it back the user info computed by this action.
>
> >Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
> > 4. The container attempts to authenticate the user
> > using the information from the form.
> >
> >If you want to do this by yourself, then yes, it is not specified in
the
> >spec how to do this. But spec implementations usually provide you
with
> >the (non-statndard) way to handle this correctly (i.e. it will
propagate
> >Principal you provided into the container). I remember some examples
> >from the Bea WebLogic server.
> >
> That's precisely what I'd like to avoid : write an authenticator for
> each and every servlet engine my app has to run on, including those I
> know nothing about :(
>
> This is IMHO a major problem in J2EE. Could JAAS help here ?
IIRC, JAAS know is part of the J2EE. Am I right? Then yes, it must be
the missing link here.
> >Not good; This would not be propagated to the other environments,
say,
> >into an EJB. Not to say that this is against any standards Java has.
> >And, same could be done using session:
> >
> > public Principal getUserPrincipal() {
> > if (session.getAttribute("userPrincipal") == null) {
> > return request.userPrincipal;
> > } else {
> > return session.getAttribute("userPrincipal");
> > }
> > }
> >
> Do you mean this code could be the one in Cocoon's Request object ?
> Well, this avoids adding a setter, but the session then becomes a
> "hidden setter". And this changes nothing for EJBs.
O, no, never. It should go into your business logic. I do not like an
idea of cluttering Cocoon request.
> BTW, Servlet 2.3 introduces Filters what allow wrapping of the Request
> and Response :
> - what if a request wrapper changes the result of getUserPrincipal ?
> Will it be propagated to EJBs ?
Don't know about it. Even more, I doubt it.
> - shouldn't we have something similar in our abstracted environment ?
Don't know. We already have something like this for cocoon: protocol. Do
you want something else/more?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>Vadim Gritsenko wrote:
>>
<snip/>
>>But the servlet spec doesn't allow a servlet to set the user
>>credential in the container.
>>
>
>It will be set for you by the container.
>
There'a misunderstanding here : if authentication is performed by an
Action, the container has already given us a request, and we cannot give
it back the user info computed by this action.
>Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
> 4. The container attempts to authenticate the user
> using the information from the form.
>
>If you want to do this by yourself, then yes, it is not specified in the
>spec how to do this. But spec implementations usually provide you with
>the (non-statndard) way to handle this correctly (i.e. it will propagate
>Principal you provided into the container). I remember some examples
>from the Bea WebLogic server.
>
That's precisely what I'd like to avoid : write an authenticator for
each and every servlet engine my app has to run on, including those I
know nothing about :(
This is IMHO a major problem in J2EE. Could JAAS help here ?
>>A thing I already though of about request locale: as Cocoon abstracts
>>the environment, couldn't we "open" the request interface by adding
>>setter methods that allows wrappers to return values set by Cocoon.
>>
>>To be clear :
>>in Environment :
>> Principal getUserPrincipal();
>> setUserPrincipal(Principal user);
>>
>>in HttpEnvironment :
>> Principal userPrincipal = null;
>>
>> public void setUserPrincipal(Principal p) {
>> this.userPrincipal = p;
>> }
>>
>> public Principal getUserPrincipal() {
>> if (this.userPrincipal == null) {
>> return this.userPrincipal;
>> } else {
>> return this.httpRequest.getUserPrincipal();
>> }
>> }
>>
>>This would allow Action-based authenticator to set the User
>>transparently to other components. The same could apply to
>>getLocale(), which could be overriden by the LocaleAction.
>>
>
>Not good; This would not be propagated to the other environments, say,
>into an EJB. Not to say that this is against any standards Java has.
>And, same could be done using session:
>
> public Principal getUserPrincipal() {
> if (session.getAttribute("userPrincipal") == null) {
> return request.userPrincipal;
> } else {
> return session.getAttribute("userPrincipal");
> }
> }
>
Do you mean this code could be the one in Cocoon's Request object ?
Well, this avoids adding a setter, but the session then becomes a
"hidden setter". And this changes nothing for EJBs.
BTW, Servlet 2.3 introduces Filters what allow wrapping of the Request
and Response :
- what if a request wrapper changes the result of getUserPrincipal ?
Will it be propagated to EJBs ?
- shouldn't we have something similar in our abstracted environment ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Greg Weinger [mailto:gweinger@itmedicine.net]
>
> <snip/>
>
> > > But the servlet spec doesn't allow a servlet to set the user
> > > credentials in the container.
> >
> > It will be set for you by the container.
> >
> > Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
> > 4. The container attempts to authenticate the user
> > using the information from the form.
> >
> > If you want to do this by yourself, then yes, it is not specified in
> > the spec how to do this.
>
> I always handle this by myself, because of design requirements. What
> are other people's experiences?
Design requirements??? The form is 100% under your control.
> > But spec implementations usually provide you with
> > the (non-statndard) way to handle this correctly (i.e. it will
> > propagate
> > Principal you provided into the container). I remember some examples
> > from the Bea WebLogic server.
> >
>
> And IHMO this sucks, because it's container-specific. I would like an
> abstraction for it within Cocoon as well, or at least a standard way
of
> handling it.
Any Cocoon level abstraction will be unportable and non-cooperative in
terms of integration with servlet, EJB containers and J2EE platform as a
whole.
> > Not good; This would not be propagated to the other environments,
say,
> > into an EJB. Not to say that this is against any standards Java has.
> > And, same could be done using session:
> >
> > public Principal getUserPrincipal() {
> > if (session.getAttribute("userPrincipal") == null) {
> > return request.userPrincipal;
> > } else {
> > return session.getAttribute("userPrincipal");
> > }
> > }
>
> That's what I was thinking; I like the idea of having "reserved"
Session
> or Request attributes that hold that the user information.
You are free to use this. Just put together couple of lines as a Cocoon
action or XSP or etc. But take into account point above: it won't work
with EJBs/other servlets/etc.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Greg Weinger <gw...@itmedicine.net>.
<snip/>
> > But the servlet spec doesn't allow a servlet to set the user
> credentials
> > in the container.
>
> It will be set for you by the container.
>
> Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
> 4. The container attempts to authenticate the user
> using the information from the form.
>
> If you want to do this by yourself, then yes, it is not specified in
the
> spec how to do this.
I always handle this by myself, because of design requirements. What
are other people's experiences?
>But spec implementations usually provide you with
> the (non-statndard) way to handle this correctly (i.e. it will
propagate
> Principal you provided into the container). I remember some examples
> from the Bea WebLogic server.
>
And IHMO this sucks, because it's container-specific. I would like an
abstraction for it within Cocoon as well, or at least a standard way of
handling it.
<snip/>
> Not good; This would not be propagated to the other environments, say,
> into an EJB. Not to say that this is against any standards Java has.
> And, same could be done using session:
>
> public Principal getUserPrincipal() {
> if (session.getAttribute("userPrincipal") == null) {
> return request.userPrincipal;
> } else {
> return session.getAttribute("userPrincipal");
> }
> }
That's what I was thinking; I like the idea of having "reserved" Session
or Request attributes that hold that the user information.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Vadim Gritsenko wrote:
>
> <snip/>
>
> >>>The main problem, I think, is that HTTP requests on their own do
not
> >>>have the concept a user built into it, which is necessary to
perform
> >>>user-based access control.
> >>>
> >>They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
> >>technical details ;). But it depends on that the browser takes care
of
> >>the protocol, which leads to: gray box pop-ups.
> >>
> >
> >As you mentioned before: form-based login. IIRC, servlet spec
describes
> >it in details. Only thing Cocoon needs is may be an action to
establish
> >user credentials in the servlet container once this form is
submitted.
> >
> <snip/>
>
> But the servlet spec doesn't allow a servlet to set the user
credentials
> in the container.
It will be set for you by the container.
Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
4. The container attempts to authenticate the user
using the information from the form.
If you want to do this by yourself, then yes, it is not specified in the
spec how to do this. But spec implementations usually provide you with
the (non-statndard) way to handle this correctly (i.e. it will propagate
Principal you provided into the container). I remember some examples
from the Bea WebLogic server.
> A thing I already though of about request locale: as Cocoon abstracts
> the environment, couldn't we "open" the request interface by adding
> setter methods that allows wrappers to return values set by Cocoon.
>
> To be clear :
> in Environment :
> Principal getUserPrincipal();
> setUserPrincipal(Principal user);
>
> in HttpEnvironment :
> Principal userPrincipal = null;
>
> public void setUserPrincipal(Principal p) {
> this.userPrincipal = p;
> }
>
> public Principal getUserPrincipal() {
> if (this.userPrincipal == null) {
> return this.userPrincipal;
> } else {
> return this.httpRequest.getUserPrincipal();
> }
> }
>
> This would allow Action-based authenticator to set the User
> transparently to other components. The same could apply to
getLocale(),
> which could be overriden by the LocaleAction.
Not good; This would not be propagated to the other environments, say,
into an EJB. Not to say that this is against any standards Java has.
And, same could be done using session:
public Principal getUserPrincipal() {
if (session.getAttribute("userPrincipal") == null) {
return request.userPrincipal;
} else {
return session.getAttribute("userPrincipal");
}
}
> Another way to make these things transparent to other components is to
> replace the request in the object model, but I've been told that
> tweaking the object model is bad ;)
Same applies to the request ;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
<snip/>
>>>The main problem, I think, is that HTTP requests on their own do not
>>>have the concept a user built into it, which is necessary to perform
>>>user-based access control.
>>>
>>They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
>>technical details ;). But it depends on that the browser takes care of
>>the protocol, which leads to: gray box pop-ups.
>>
>
>As you mentioned before: form-based login. IIRC, servlet spec describes
>it in details. Only thing Cocoon needs is may be an action to establish
>user credentials in the servlet container once this form is submitted.
>
<snip/>
But the servlet spec doesn't allow a servlet to set the user credentials
in the container.
A thing I already though of about request locale : as Cocoon abstracts
the environment, couldn't we "open" the request interface by adding
setter methods that allows wrappers to return values set by Cocoon.
To be clear :
in Environment :
Principal getUserPrincipal();
setUserPrincipal(Principal user);
in HttpEnvironment :
Principal userPrincipal = null;
public void setUserPrincipal(Principal p) {
this.userPrincipal = p;
}
public Principal getUserPrincipal() {
if (this.userPrincipal == null) {
return this.userPrincipal;
} else {
return this.httpRequest.getUserPrincipal();
}
}
This would allow Action-based authenticator to set the User
transparently to other components. The same could apply to getLocale(),
which could be overriden by the LocaleAction.
Another way to make these things transparent to other components is to
replace the request in the object model, but I've been told that
tweaking the object model is bad ;)
Thoughts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Daniel Fagerstrom [mailto:Daniel.Fagerstrom@lentus.se]
>
> Greg Weinger wrote:
<snip/>
> > > Browsers know about the HTTP authentication protocol, and if you
use
> > that,
> > > they will send you username and password automatically.
> >
> > Where do you retrieve them? AFAIK they're not available in the
Servlet
> > API.
>
> You can use getAuthType(), getRemoteUser(), getUserPrincipal(),
> and isUserInRole(java.lang.String role) in the HttpServletRequest
interface.
> Password is however not availible as all the above methods rely on
that
> the servlet container takes care of user authentication.
>
> > Anyway, graphic designers loathe the HTTP authentication protocol.
Your
> > only choice of input form is that gray box that pops-up (maybe not
in
> > mozilla XUL, but the world isn't there yet). In most cases, you'll
be
> > wanting to use HTTP forms.
>
> Yes it is disturbing that one have to choose between design and
security
> level: Form based login is ok if you use HTTPS or if you don't think
(or
> care if) someone taping your wire. HTTP digest authentication gives
you
> much higher security level of security against wire tapping if you
don't
> want to use HTTPS, but in this case you will get gray box pop-ups in
the
> browser :(
>
> > The main problem, I think, is that HTTP requests on their own do not
> > have the concept a user built into it, which is necessary to perform
> > user-based access control.
>
> They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
> technical details ;). But it depends on that the browser takes care of
> the protocol, which leads to: gray box pop-ups.
As you mentioned before: form-based login. IIRC, servlet spec describes
it in details. Only thing Cocoon needs is may be an action to establish
user credentials in the servlet container once this form is submitted.
> > That information has to be established programmatically. My thought
> > was, what if we built that concept into Cocoon?
It is built in into servlet spec. See answer from Greg Weinger (above).
> Yes, then I think that one either have to suport rfc2617 in Cocoon,
which
> seem tricky, or use session based security, (IIRC there already are
som
> actions in Cocoon that takes care of that). Implementing own support
for
> passing credentials back and forth for each request, seem to
complicated
> to me.
And already done by *any* servlet engine.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Daniel Fagerstrom <Da...@lentus.se>.
Greg Weinger wrote:
<snip/>
> > Browsers know about the HTTP authentication protocol, and if you use
> that,
> > they will send you username and password automatically.
>
> Where do you retrieve them? AFAIK they're not available in the Servlet
> API.
You can use getAuthType(), getRemoteUser(), getUserPrincipal(),
and isUserInRole(java.lang.String role) in the HttpServletRequest interface.
Password is however not availible as all the above methods rely on that
the servlet container takes care of user authentication.
> Anyway, graphic designers loathe the HTTP authentication protocol. Your
> only choice of input form is that gray box that pops-up (maybe not in
> mozilla XUL, but the world isn't there yet). In most cases, you'll be
> wanting to use HTTP forms.
Yes it is disturbing that one have to choose between design and security
level: Form based login is ok if you use HTTPS or if you don't think (or
care if) someone taping your wire. HTTP digest authentication gives you
much higher security level of security against wire tapping if you don't
want to use HTTPS, but in this case you will get gray box pop-ups in the
browser :(
> The main problem, I think, is that HTTP requests on their own do not
> have the concept a user built into it, which is necessary to perform
> user-based access control.
They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
technical details ;). But it depends on that the browser takes care of
the protocol, which leads to: gray box pop-ups.
> That information has to be established programmatically. My thought
> was, what if we built that concept into Cocoon?
Yes, then I think that one either have to suport rfc2617 in Cocoon, which
seem tricky, or use session based security, (IIRC there already are som
actions in Cocoon that takes care of that). Implementing own support for
passing credentials back and forth for each request, seem to complicated
to me.
> > I think that what you propose here can be handled with actions, so there
> > is probably no need for new sitemap constructions, although they could
be
> > more
> > conscise.
>
> That's what I was wondering; it's not necessary, but if AC is used so
> frequently, for almost every URI, would that concision be useful?
IMHO as it is possible to experiment with the things that you are sugesting
without extending any sitemap concepts, it is better to do that, concision
is not a goal in it self. However if you want to be able to ask Cocoon about
security, "ls -l", as you sugested in your RT (Cocoon as OS), it seems
nescesary to have an explicit description of the AC rules. This would
also be useful if one want WebDAV access to Cocoon (where "ls -l"
corresponds to PROPFIND with some kind of ACL argument), I should add, that
"ls" is hard (to say the least) to integrate in Cocoon as you can use
wildcards in the sitemap (Berin and Stefano had recently a discussion
about something related in the context of hash table based "map:match"
implementation in the sitemap, don't rememeber in what thread).
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Greg Weinger <gw...@itmedicine.net>.
> The servlet API is (AFAIU) based on an authorization model where
> the servlet container is suposed to take care about:
>
> * the HTTP authentication protocol (ftp://ftp.isi.edu/in-
> notes/rfc2617.txt)
> * user authorization (in practice: user and password DB)
> * role handling
>
> IMHO the first point is an appropriate concern for the servlet
container
> while the rest of the points are application concerns.
Right. It's nice that Tomcat provides user authorization, but relying
on it makes your apps less portable.
> > I started with the User/Group based system, since it is
> > ubiquitous. (I think
> > Brian was touching on this earlier). To bring that to the
> > Cocoon/web world, we
> > need to assume that every URI request has a user, password, and a
> > group. If this
> > information does not exist in the standard places (Request,
> > Session, or a new
> > User object in the object model), than a default user, password,
> > and group is
> > assumed (anonymous). That means we'd have "special" request
> > parameters, a la
> > cocoon-action, cocoon-user, cocoon-pass, cocoon-group, which is
> > ugliness to be
> > sure, but ugliness that goes away with Schecoon.
>
> It seem a little bit complicated (and insecure) to make shure that the
> client send all this information, (but maybe I am missing something).
> Browsers know about the HTTP authentication protocol, and if you use
that,
> they will send you username and password automatically.
Where do you retrieve them? AFAIK they're not available in the Servlet
API.
Anyway, graphic designers loathe the HTTP authentication protocol. Your
only choice of input form is that gray box that pops-up (maybe not in
mozilla XUL, but the world isn't there yet). In most cases, you'll be
wanting to use HTTP forms.
The main problem, I think, is that HTTP requests on their own do not
have the concept a user built into it, which is necessary to perform
user-based access control. That information has to be established
programmatically. My thought was, what if we built that concept into
Cocoon?
> I think that what you propose here can be handled with actions, so
there
> is
> probably no need for new sitemap constructions, although they could be
> more
> conscise.
>
That's what I was wondering; it's not necessary, but if AC is used so
frequently, for almost every URI, would that concision be useful?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Greg Weinger wrote:
> You beat me to the punch, dammit! ;-) Actually, I hadnt thought of
> resource-based security, an interesting concept. I strongly
> feel that Cocoon
> needs to make ACL functionality available, in a clean way. Why
> does Tomcat
> provide its own database security mechanism? They're trying to
> fill a void I
> personally would like my webapp framework to handle, for
> portability. I don't
> want to lose my ACL functionality when my client makes me switch
> to WebSphere, or
> vice versa.
I agree. The servlet API is (AFAIU) based on an authorization model where
the servlet container is suposed to take care about:
* the HTTP authentication protocol (ftp://ftp.isi.edu/in-notes/rfc2617.txt)
* user authorization (in practice: user and password DB)
* role handling
IMHO the first point is an appropriate concern for the servlet container
while the rest of the points are application concerns. Of course I would
like to have a nice standardized handling of users for all aplications. But
in several projects that I have been involved in there have been legacy DB:s
with user data that we had to use. So at least from my experience, user
handling is a application concern.
So AFAIU either one have to put all authorization in the servlet container,
which for Tomcat often means that one have to write a custom realm (have
done it and didn't like it). Or one have to let the application framework
take care of it. I would prefer the later alternative and having all
authorization taken care of from Cocoon, (but I do not volunteer to
integrate the HTTP authentication protocol ;) ).
> Here is how Ive been thinking about security, which I think
> maximizes puggability into existing ACL systems, and neatly seperates this
> concern island from the others.
>
> I started with the User/Group based system, since it is
> ubiquitous. (I think
> Brian was touching on this earlier). To bring that to the
> Cocoon/web world, we
> need to assume that every URI request has a user, password, and a
> group. If this
> information does not exist in the standard places (Request,
> Session, or a new
> User object in the object model), than a default user, password,
> and group is
> assumed (anonymous). That means wed have special request
> parameters, a la
> cocoon-action, cocoon-user, cocoon-pass, cocoon-group, which is
> ugliness to be
> sure, but ugliness that goes away with Schecoon.
It seem a little bit complicated (and insecure) to make shure that the
client send all this information, (but maybe I am missing something).
Browsers know about the HTTP authentication protocol, and if you use that,
they will send you username and password automatically.
> A request URI can be protected by a permission (I suppose a
> pipeline could, too,
> but that could best be decided by others). It can also be left
> unprotected
> (everyone).
>
> <map:match src=app/** permission=internet>
> <map:generate/>
> <map:serialize/>
> </map:match>
>
> Permissions are sitemap-defined:
>
> <map:permissions>
> <map:permission name=internet validate=user>
> <map:user>anonymous</map:user>
> <map:group>anonymous</map:group>
> </map:permission>
> <map:permission name=intranet validate=database>
> <map:group>company</map:group>
> </map:permission>
> <map:permission name=admin validate=database>
> <map:group>managers</map:group>
> </map:permission>
> <map:permission name=mydepartment validate=ip/>
> </map:permissions>
>
> Permissions can thus be heirarchical:
>
> <map:permission name=mydepartment validate=ip>
> <map:parameter name=address value=149.142.22.x/>
> <map:permission validate=database>
> <map:group>company</map:group>
> </map:permission>
> </map:permission>
>
> Permissions are validated by a set of validatior objects; wed
> supply the most
> common ones (maybe authenticator is a better semantic ):
I think that what you propose here can be handled with actions, so there is
probably no need for new sitemap constructions, although they could be more
conscise.
> <map:validators>
> <map:validator type=user src=FileBasedUserValidator.java>
> <scope>Request</scope><!-- or Sesison, Schecoon, etc. -->
> </map:validator>
> <map:validator type=ntuser src=NTMappedValidator.java/>
> <map:validator type=db src=DatabaseValidator.java/>
> <map:validator type=ip src=IPBasedValidator.java/>
> <map:validator type=http src=HTTPChallengeValidator.java.>
> </map:validators>
Yes, there is probably need for several different kinds of validators.
> That way we can plug our authentication scheme into any number
> of existing
> methods, including the neat Slide-based scheme proposed by Daniel.
>
> The webapp writer or site administrator is responsible for
> writing login pages to
> supply user, pass, and group parameters, only once for Session scope, and
> embedding it in pages if they want Request scope).
>
> The only other thing I think the sitemap developer should be
> concerned with is
> error-handling. What happens when access is denied? In both
> static resource and
> web application contexts, that behavior needs to be customized. Just use
> handle-error:
>
> <map:handle-error type=access-denied>
> <!-- add your custom login page, a standard message, what have you -->
> </map:handle-error>
>
> So how does this monster behave? Take this sitemap example:
>
> <map:match src=admin/** permission=admin>
> <map:generate/>
> <map:serialize/>
> </map:match>
>
> If you have admin access, then everything is fine. If not, an
> AccessException is
> thrown, which either bubbles up to the top, or is handled by the
> handle-error
> defined in the sitemap. I dont think that anything Ive
> proposed would be
> incompatible with the Resource-based security, which is similar
> to the pipeline
> caching approach.
That is a good parallell!
<snip/>
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Greg Weinger <gw...@itmedicine.net>.
You beat me to the punch, dammit! ;-) Actually, I hadnt thought of
resource-based security, an interesting concept. I strongly feel that Cocoon
needs to make ACL functionality available, in a clean way. Why does Tomcat
provide its own database security mechanism? They're trying to fill a void I
personally would like my webapp framework to handle, for portability. I don't
want to lose my ACL functionality when my client makes me switch to WebSphere, or
vice versa. Here is how Ive been thinking about security, which I think
maximizes puggability into existing ACL systems, and neatly seperates this
concern island from the others.
I started with the User/Group based system, since it is ubiquitous. (I think
Brian was touching on this earlier). To bring that to the Cocoon/web world, we
need to assume that every URI request has a user, password, and a group. If this
information does not exist in the standard places (Request, Session, or a new
User object in the object model), than a default user, password, and group is
assumed (anonymous). That means wed have special request parameters, a la
cocoon-action, cocoon-user, cocoon-pass, cocoon-group, which is ugliness to be
sure, but ugliness that goes away with Schecoon.
A request URI can be protected by a permission (I suppose a pipeline could, too,
but that could best be decided by others). It can also be left unprotected
(everyone).
<map:match src=app/** permission=internet>
<map:generate/>
<map:serialize/>
</map:match>
Permissions are sitemap-defined:
<map:permissions>
<map:permission name=internet validate=user>
<map:user>anonymous</map:user>
<map:group>anonymous</map:group>
</map:permission>
<map:permission name=intranet validate=database>
<map:group>company</map:group>
</map:permission>
<map:permission name=admin validate=database>
<map:group>managers</map:group>
</map:permission>
<map:permission name=mydepartment validate=ip/>
</map:permissions>
Permissions can thus be heirarchical:
<map:permission name=mydepartment validate=ip>
<map:parameter name=address value=149.142.22.x/>
<map:permission validate=database>
<map:group>company</map:group>
</map:permission>
</map:permission>
Permissions are validated by a set of validatior objects; wed supply the most
common ones (maybe authenticator is a better semantic ):
<map:validators>
<map:validator type=user src=FileBasedUserValidator.java>
<scope>Request</scope><!-- or Sesison, Schecoon, etc. -->
</map:validator>
<map:validator type=ntuser src=NTMappedValidator.java/>
<map:validator type=db src=DatabaseValidator.java/>
<map:validator type=ip src=IPBasedValidator.java/>
<map:validator type=http src=HTTPChallengeValidator.java.>
</map:validators>
That way we can plug our authentication scheme into any number of existing
methods, including the neat Slide-based scheme proposed by Daniel.
The webapp writer or site administrator is responsible for writing login pages to
supply user, pass, and group parameters, only once for Session scope, and
embedding it in pages if they want Request scope).
The only other thing I think the sitemap developer should be concerned with is
error-handling. What happens when access is denied? In both static resource and
web application contexts, that behavior needs to be customized. Just use
handle-error:
<map:handle-error type=access-denied>
<!-- add your custom login page, a standard message, what have you -->
</map:handle-error>
So how does this monster behave? Take this sitemap example:
<map:match src=admin/** permission=admin>
<map:generate/>
<map:serialize/>
</map:match>
If you have admin access, then everything is fine. If not, an AccessException is
thrown, which either bubbles up to the top, or is handled by the handle-error
defined in the sitemap. I dont think that anything Ive proposed would be
incompatible with the Resource-based security, which is similar to the pipeline
caching approach. That would be a lot of added complexity, but then thats an
implementation and customization issue. My sense is that resource-based access
control should be disabled by default; that customization should be available if
necessary, but in most cases it seems like overkill.
How does this work? I have to admit Im not overly familiar with sitemap
internals, but my feeling is that these things should be this seemless to the
sitemap user/writer. Magic happens here. This becomes much easier when youre
thinking about a Schecoon context, where you theoretically dont have to think
about maintaining state across HTTP connections. We might need two branching
hierarchies of ACL handlers to handle both stateless and stateful web contexts.
Thats all I can muster for now. . .
Greg Weinger
UCLA Teleradiology
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Judson Lester wrote:
<snip/>
> Resource based AC seems like an administrative nightmare.
With Cocoon as it is today I agree, for resource based AC to be atractive
there must be a underlying CMS that all resources are accessed through. In
this scenario the CMS is resposbible for AC of resources and Cocoon is
responsible for calculating access rights for the composition of resources.
> 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.
I guess you refer to the SQL query example? I am afraid it was better as an
argument against than for my conclusions ;) I think for hierarcical
datastructures: file systems, XML DB, LDAP it is fairly straightforward (at
least conceptually) to protect with AC concepts like those in WebDAV ACL.
It would however be quite hard to write an SQL transformer that draws any
conclusions about access rights from a SQL query, in this case request URI
protection is probably the only plausible option.
> In fact, I forsee establishing groups that have access rights to
> the resources needed for any one URI, and adding users to them,
WebDAV ACL allow you to group users, as well as resources and operations in
any hierachy you like.
> 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.
Flexiblity is not the main issue. It is that (IMHO) in most cases the
content (the resources) are more natural units of protection than the
various views of them (the request URI:s), so I would prefer a resource
based AC system, but as this would require integration with a CMS, request
URI based AC is much more realistic as a short term goal.
/Daniel Fagerström
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Judson Lester <ju...@irev2.com>.
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
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
> Daniel Fagerstrom wrote:
>
<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? how about
> aggregation? how about selectors?
>
This stuff mostly brushes my hair as it goes by, but what about moving these
problems to the XSLT? I deal mainly with sites that get pregenerated before
going live - so be gentle :) ? Here goes...
First, I think development cocoon and deployment cocoon should be two
different things. They have totally different needs. What I describe below
would be for the development cocoon which could be exported to the
deployment cocoon. In addition, I would like to see these things be file
based (...ducking...) - so GUIs can be easily created - so administration
can be moved to administrators.
Content aggregation can be handled by the xsl document function. These
things can be keyed and cached for excellent performance. You keep all your
XML content/configs and XSLTs behind WEB-INF so they are secure. Here is a
simple example (not keyed):
[[ a transformation is performed against something like:
<page xsl_fileref="body2col.xsl" id="p0000000001" is_index="true"
display_label_link="true" label="Page 1" title="Page One">
<content>
<xml id="index_en.xml" position="center_panel"/>
<xml id="blurb.xml" position="right_panel"/>
</content>
</page>
]]
[[ this part of the transformation finds content and starts the
transformation on each content piece:
<xsl:template match="content">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="xml">
<xsl:variable
name="content_config"
select="document(concat($context,
'/WEB-INF/styling/content.xml'))/config/content"/>
<xsl:variable
name="xml_id"
select="@id"/>
<xsl:variable
name="content_xml"
select="$content_config/content-xml[@id=$xml_id]"/>
<xsl:variable
name="content_folder"
select="$content_xml/@folder"/>
<xsl:apply-templates
select="document(concat($context,
'/WEB-INF/_sitexml',$content_folder, $xml_id))/*">
<xsl:with-param name="xml_id" select="$xml_id"/>
</xsl:apply-templates>
</xsl:template>
]]
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by giacomo <gi...@apache.org>.
On Wed, 6 Feb 2002, 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?
Nothing is more annoying than presenting link to resources which are
outside the requestors permission. Imagine you have content to describe
a navigation list. Would you write a separate one for all possible
permissions? I'd say no. You probably describe which permission is
required to include nodes of your content into the pipeline either into
the content or in a separate document (XLink approach).
<snip/>
> > 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.
Yup. We havn't had the time to think more about it as we need to have
the port work under Cocoon ASAP (yes , I'm involved in the port of the
Wyona-CMS from their XPS system to Cocoon).
> > 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
> :)
They use a subset of the oasis-open.org ACML proposal donnated by IBM
there. I think it is a good start for discussion formats.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> 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.
Hmmm, what about aggregation? what about a web application? the only
meaninful unit of protection I see is the URI and this doesn't require
component-granular AC.
> 2. To be able to handle protection of your content, a CMS would be nice to
> have.
Of course, but this has very little to do with Cocoon managing AC
directly: AC at the editing level will very likely *not* be performed by
Cocoon but by some higher logic since it resides in a totally different
concern island (at least, that's how I see it)
> 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.
In my ideal architecture, a CMS will make transparent all the content
that you don't have access to.
So, yeah, Cocoon needs some way of obtaining use information (but
authentication) but I don't see any reason to have lower-level
granularity directly in Cocoon.
> 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.
Ok, now I see where you are coming from...but I can't find myself
resonating with this... what do others think?
> <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.
Yes, I agree that we should not cure something that we don't know it's
ill.
> > > 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.
Ah, this is different and I agree with you here, this might be a
desirable functionality
> <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.
well, it might be more complex than this: don't assume your users know
what you know about the application. If something doesn't work, you have
to tell him why and how to fix this before jumping back on 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.
Ok then, let's see: if we were to add AC semantics to the sitemap, how
would you do it?
I mean: how would you patch the current sitemap
markup/semantics/behavior?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Royal wrote:
>
> On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
> > my personal opinion is that I don't see anything that justifies the
> > inclusion of AC at the sitemap level since AC is just another action.
>
> i agree. it would make a great pluggable webapp though.
Oh, absolutely, but on second though, looking at the sitemap semantics,
an 'aggregation' is just another way of 'generating' content. But since
this has a specific behavior in respect of cocoon views and such, and
it's widely used, it got included and people love it.
It could be the same with AC (besides, Apache does this).
So, let's try to come up with some AC-augmentation for the sitemap and
see where this leads us to... if it turns up to be 'feasible' in terms
of verbosity and additional complexity of the semantics, we'll do that,
otherwise, we'll consider AC part of the general webapp modularity.
Carsten, don't you have anything to say here (you are about to donate
some AC logic along with your portal additions, isn't it?)
> a "blocklet" if you will; some actions, transformers and maybe a custom
> protocol handler could do it all. AC might be a great first candidate for
> hammering out a component app API. (which could maybe be applied via
> namedspaced attributes against the standard sitemap language?
Hmmm, let's see...
> <map:sitemap>
> <map:components>
> <map:blocklets>
> <map:blocklet xmlns:ac="http://apache.org/cocoon/ac/1.0"
> src="org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap"/>
> </map:blocklets>
> </map:components>
>
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="protected/**">
> <map:generate src="context://secret/**" ac:check="{1}"/>
well, this is not an attribute, but an element... should be something
like
<ac:check>
<map:generate>
...
</ac:check>
but this would open the door for almost anything and this scares the
crap out of me.
> <map:transform>
> ...etc...
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> then in org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap
>
> <map:sitemap>
> <map:components>
>
> ...standard stuff...
>
> </map:components>
>
> <map:pipelines>
> <map:pipeline name="check">
> <map:parameter name="resource"/> <!-- i don't know what to call this, but
> similar to xsl:param, declaring a parameter name -->
>
> <map:act type="check-logged-in">
> <map:act type="can-read-resource">
> <map:parameter name="username" value="{username}"/>
> <map:parameter name="resource" value="{../resource"/>
>
> <map:return/>
You are comping up with a procedural language... no, I think this is
heading in the wrong direction.
> </map:type>
>
> <map:call resource="access-denied"/>
> </map:act>
>
> <map:call resource="login">
> <map:parameter name="requested-resource" value="resource"/>
> </map:call>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
> ok, only a couple new sitemap constructs here. we have map:blocklet at the
> top, which defines the access controller, giving it a namespace to act in.
> the src attribute points to another sitemap that defines the blocklet's
> actions.
>
> the blocklet is called when a namespaced attribute appears. the blocklet
> would be called before the generate. (potential pitfall: multiple blockets on
> a single element, what order are they called, no xml contract for attribute
> ordering afaik).
Exactly: xml attributes don't have numbering or order for a reason and
you shouldn't be using something that *does* require order using
attributes.
> the name of the attribute corresponds to the name of a
> pipeline in the blocklet sitemap. parameters could be passed either by the
> attribute contents or via the implicit parameter maps of the sitemap. in the
> first case, maybe declaring map:parameter elements under a pipeline could
> signify the order the attributes are. (the implicit params might be best..)
>
> then you would basically drop into a pipeline in the blocklet sitemap. the
> only new element there is a map:return element which would return control to
> the original sitemap.
No offense intended, but I find this very ugly. :/
> rules on a blocklet pipeline could be relaxed, generators and serializers not
> required, so a blocklet call could be placed in the middle of a pipeline
> (think skin, the main contract would be an xml scheme contract, but you could
> also pass parameters to the blocklet setup in the initial sitemap, maybe
> there
> passing in the skins you want to use to the skin engine).
>
> rough ideas really. seems to jump out a bit more at me as far as seeming
> simple on the top. some of your previous example sketches didn't immediately
> 'click' in my head, but i may just need to stare at them a bit more.
Oh, no problem Pete, we need to place everything on the table during
RT-based brainstorms and for sure they will trigger something that will
end up in the right direction.
> just stirring the pot.
:) yeah, that's good visuals!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
> my personal opinion is that I don't see anything that justifies the
> inclusion of AC at the sitemap level since AC is just another action.
i agree. it would make a great pluggable webapp though.
a "blocklet" if you will; some actions, transformers and maybe a custom
protocol handler could do it all. AC might be a great first candidate for
hammering out a component app API. (which could maybe be applied via
namedspaced attributes against the standard sitemap language?
<map:sitemap>
<map:components>
<map:blocklets>
<map:blocklet xmlns:ac="http://apache.org/cocoon/ac/1.0"
src="org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap"/>
</map:blocklets>
</map:components>
<map:pipelines>
<map:pipeline>
<map:match pattern="protected/**">
<map:generate src="context://secret/**" ac:check="{1}"/>
<map:transform>
...etc...
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
then in org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap
<map:sitemap>
<map:components>
...standard stuff...
</map:components>
<map:pipelines>
<map:pipeline name="check">
<map:parameter name="resource"/> <!-- i don't know what to call this, but
similar to xsl:param, declaring a parameter name -->
<map:act type="check-logged-in">
<map:act type="can-read-resource">
<map:parameter name="username" value="{username}"/>
<map:parameter name="resource" value="{../resource"/>
<map:return/>
</map:type>
<map:call resource="access-denied"/>
</map:act>
<map:call resource="login">
<map:parameter name="requested-resource" value="resource"/>
</map:call>
</map:pipeline>
</map:pipelines>
</map:sitemap>
ok, only a couple new sitemap constructs here. we have map:blocklet at the
top, which defines the access controller, giving it a namespace to act in.
the src attribute points to another sitemap that defines the blocklet's
actions.
the blocklet is called when a namespaced attribute appears. the blocklet
would be called before the generate. (potential pitfall: multiple blockets on
a single element, what order are they called, no xml contract for attribute
ordering afaik). the name of the attribute corresponds to the name of a
pipeline in the blocklet sitemap. parameters could be passed either by the
attribute contents or via the implicit parameter maps of the sitemap. in the
first case, maybe declaring map:parameter elements under a pipeline could
signify the order the attributes are. (the implicit params might be best..)
then you would basically drop into a pipeline in the blocklet sitemap. the
only new element there is a map:return element which would return control to
the original sitemap.
rules on a blocklet pipeline could be relaxed, generators and serializers not
required, so a blocklet call could be placed in the middle of a pipeline
(think skin, the main contract would be an xml scheme contract, but you could
also pass parameters to the blocklet setup in the initial sitemap, maybe
there
passing in the skins you want to use to the skin engine).
rough ideas really. seems to jump out a bit more at me as far as seeming
simple on the top. some of your previous example sketches didn't immediately
'click' in my head, but i may just need to stare at them a bit more.
just stirring the pot.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Stefano Mazzocchi <st...@apache.org>.
Greg Weinger wrote:
> I see two propositions:
>
> 1. Access Control should be integrated into the sitemap.
>
> 2. The sitemap is sufficient; we can provide out-of-the-box AC
> with the existing framework, or address that in the upcoming
>
> componentized Cocoon App architecture. [Stefano, please
> share more of your thoughts on that].
my personal opinion is that I don't see anything that justifies the
inclusion of AC at the sitemap level since AC is just another action.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Greg Weinger <gw...@itmedicine.net>.
> > So, how can access control (AC) be integrated in Cocoon? And how
much
> > would integration of AC need to affect the current architecture?
And, prior to this, what justifies integrating AC into the sitemap
semantic?
How do we determine if AC is something that warrants being "promoted" to
the sitemap level? What general principles can we apply?
At some level, AC looks like it belongs to the logic domain (vs.
Content, Presentation). But URI matchers and selectors look that way
too. What is it about Actions that has made them unsuccessful or
undesirable within the sitemap?
If the sitemap is like a mirror of the different employee roles in a web
publishing enterprise, then I think that the Security Managers, the
Gatekeepers, deserve their small island in the archepelago, alongside
the programmers, the writers, visual artists, and, of course, the site
architect.
I see two propositions:
1. Access Control should be integrated into the sitemap.
2. The sitemap is sufficient; we can provide out-of-the-box AC
with the existing framework, or address that in the upcoming
componentized Cocoon App architecture. [Stefano, please
share more of your thoughts on that].
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Access Control (was [RT] Cocoon as OS)
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org