You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2003/06/18 13:52:08 UTC
Access Control Draft V2
Hi Lenya developers,
here is another sketch of the access controlling.
The workflow part is moved from the policy to the
authorizer.
Please add your comments.
Andreas
Re: Access Control Draft V2
Posted by Andreas Kuckartz <A....@ping.de>.
Andreas Hartmann
> The problem is that we (Michael, Christian and I) needed three
> extensive meetings to fully (?) understand the concepts, and I don't
> have the time to explain everything on the list.
I also had my problems to completely understand the graphics. But I think
that it was very good that you sent the graphics to the list. This level of
public conceptual work is not normal for Open Source projects.
One suggestion. It might be possible to explain graphics in audio or video
and make that available on the net. This probably could be done with much
less effort than writing a text. Replying would perhaps become more
problematic...
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Access Control Draft V2
Posted by Andreas Hartmann <an...@apache.org>.
Alex McLintock wrote:
>
> I don't mean to sound ungrateful but a diagram by itself without any
> explanation is almost useless.
> Have I missed a definition of what all the components are?
Your objection is more than justified.
The problem is that we (Michael, Christian and I) needed three
extensive meetings to fully (?) understand the concepts, and I don't
have the time to explain everything on the list. There are some
messages on the list preceding this one and explaining some of
the concepts. The "flow diagrams" are probably the most useful
ones.
I started a wiki page to define some of the terms:
http://wiki.cocoondev.org/Wiki.jsp?page=LenyaAccessControl
Sorry for this lack of information, but we will probably commit
the first prototypical implementation in the beginning of next
week, this will simplify collaboration.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: Access Control Draft V2
Posted by Alex McLintock <al...@owal.co.uk>.
I think Andreas wrote:
> >>
>Hi Lenya developers
>
>here is another sketch of the access controlling.
><<
I don't mean to sound ungrateful but a diagram by itself without any
explanation is almost useless.
Have I missed a definition of what all the components are?
Apart from that it looks brilliant. :-)
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Access Control Draft V2
Posted by Andreas Hartmann <an...@apache.org>.
Hi Christian,
the following statements reflect only my current understanding, please
correct my if I got something wrong.
Christian Egli wrote:
> 1. I'm a little bit worried about the possibility of duplication
> between Policies and the Workflow, i.e. the Workflow could allow a
> request but the Policy wouldn't or vice versa. Ho do we make sure
> such cases don't happen?
Such cases will happen. That's why we use logical AND to allow a
request only if both "filters" let it through.
> 2. How does this solution allow for the editing of groups and roles?
> Where is this information stored? In the Policy or in the {i|g|r}ml
> files?
There is no immediate connection from AC objects (u,g,m,w) to roles,
a role is always connected to an AC object together with a URI space.
We have to figure out a performant solution where to put the URIs
in the design. This will probably be the basis for the persistence
implementation.
> 3. How do you get the roles? Currently you have to have a User to get
> roles. We would either have to change the Identity to also contain
> groups or we would need to put the User in the session (as it is
> done with the Identity currently).
The workflow must be able to access all information that is required to
get the roles. Therefore the session must contain:
a) the roles that are allowed at this URI themselves
b) the most specific AC object(s) that passed the authorizer and the URI
a) supports information hiding and performance, b) supports flexibility.
----------------------------------------------------------------------
The following rules are valid:
1. The privilege set of a user or a machine is the union set of its
own privileges, the privileges of all groups it belongs to and the
privileges of the world.
2. The privilege set of a group is the union set of its own privileges
and the privileges of the world.
3. The privilege set of the world contains only its own privileges.
----------------------------------------------------------------------
I can imagine the following AC object constellations to be allowed at
a certain URI:
1. a user and a subset of the groups it belongs to
2. a machine and a subset of the groups it belongs to
3. a set of groups (*)
4. the world
5. any sets containing objects from 1. to 4.
(*) This is the current policy implementation (a group can be given
access independently of a user / machine). We probably won't
allow this case when we see groups as collections of users and
machines.
Tomorrow I will try to extend the sketch with these concepts.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Access Control Draft V2
Posted by Christian Egli <ch...@wyona.com>.
Andreas Hartmann <an...@apache.org> writes:
> Hi Lenya developers,
>
> here is another sketch of the access controlling.
>
> The workflow part is moved from the policy to the
> authorizer.
>
> Please add your comments.
This looks like a way to solve the problem. It's not the simplest
solution but it could probably done without changing too much.
A few issues:
1. I'm a little bit worried about the possibility of duplication
between Policies and the Workflow, i.e. the Workflow could allow a
request but the Policy wouldn't or vice versa. Ho do we make sure
such cases don't happen?
2. How does this solution allow for the editing of groups and roles?
Where is this information stored? In the Policy or in the {i|g|r}ml
files?
3. How do you get the roles? Currently you have to have a User to get
roles. We would either have to change the Identity to also contain
groups or we would need to put the User in the session (as it is
done with the Identity currently).
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: Access Control Draft V2
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
>>
Hi Lenya developers,
here is another sketch of the access controlling.
<<
were you able to clarify the respective uses
of policies and roles, and eliminate duplication?
at first glance the document looks like this
issue hasn't been resolved yet
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org