[Zope] Can Role include an other Role?

Thu, 17 Jan 2002 15:58:40 +0100

From: "Ove Ruben R Olsen" <ruben@noia.no>
To: "Lennart Regebro" <lennart@regebro.nu>; <zope@zope.org>

> >You create two roles, A and B. You give all users in group A role A, all
> >users in group B role B.
> >You give users in group C roles A and B.
>
> In theory this is just fine - but in practice this may be a pain.

There are of course always cases where another paradigm would be more
practical. I this case I can't see what the problem is or in what way groups
would help.

> So - suddenly Management decides that user 2, 5, 15, 21 and 25 should av
> the right to alter existing information i ObjectX.
> Currently we would change the security on ObjectX  concerning the given
> users. That may currently be done the hard way or a easier way.

OK, so user 2, 5, 15, 21 and 25 has had a change of roles. They should then
get a different set of roles. This is the only way to do it in Zope, since
users can't have individual permissions. Groups doesn't make anything easier
or harder in that case.

> If we had access to groups we could then create GroupC and put the given
> users into that group.

So in this case you create a role and give these users that role. This is
not harder in any way. In fact it is so similar that people often confuse
roles and groups, and think that the roles system in fact are groups... :-)

> I belive that Zope should support both the currenct scheme and a new
scheme
> involving groups.

Just adding groups would give no additional functionality, just increased
complexity. Much more than that is needed to add any significant
improvement. I have written a long text about this (which I'm going to
update someday), so I include it. It refers to another discussion, but I
don't think that will confuse things too much.

------

########
# Intro
########

Security is a complex subject, and I'm not that good at explaining things
and to make things harder for me, I'm going to start with making a lot of
people angry (as usual):

When thinking about Zope security, one needs to get rid of the frame of mind
one is in when it comes to operating system security. Zope is not an
operating system, and the security should therefore not be designed as if it
were an OS. Also, most here are Unix people, and you therefore tend to think
Unix permission and rights, and I'm sorry, but the Unix permissions/rights
system sucks. It really, really, really sucks. So forget Unix security. Zope
security should not work anything like the Unix permission system does,
because it does nearly everything completely wrong, not to mention the fact
that is regards file security and not security for an object oriented
system.

So, angry yet? OK. Take a deep breath and stop being angry and I'll
continue.

This text attempts to outline how I think a security system for Zope3 should
look like. Some parts are very general and not even Zope specific; some
parts are extremely Zope specific. I hope you don't mind that I mix these
things up completely.

##############
# Definitions
##############

- A principal is an entity that can be authenticated. This is similar
to a user except that we don't require principals to be humans --
they could be programs, or servers, or companies, or aliens,
whatever.

- A permission is a token that is used as a requirement for an
operation. A principal is allowed to carry out an operation
if the principal retains the required permission.

- A role is an organizational position. A principal can have none, one or
several roles in a particular context.

Credit should go where credit is due. The definition for principal is Guido'
s. So is the definition for permission, except that I replaced the mapping
explanation with a more general and abstract one of "retaining" a permission
to do the action.

#############
# Principals
#############

A principal is an entity that can be authenticated. If principals get called
users or accounts in the user-interface is completely unimportant to me.
For this document, I will call them principals since they are not
necessarily users and they are not always accounts.

Principals should have properties like full name and e-mail. Preferably the
set of properties a principal has should be defined in the acl_user folder.

Principals should be created in a hierarchy. This would enable the creation
of X.400 style directories and easier integration with X.400 or LDAP
directories. I'll call the branches of the hierarchy for "containers"
because I can't think of anything better.

Although the acl_user folder will end up with it's own hierarchy there will
still be a need for adding several acl_user folders to a system. The
hierarchy of users will lessen the need for the users to be "additive"
though. The security system will probably only need to traverse until one
acl_user folder is found, (or rather acquire it) instead of continue
looking.

The hierarchical user folder will also in a straight and easy way solve most
grouping problems, but not all. See "Grouping" for further thoughts on that
subject.

### The Anonymous principal

On any web-system there should be one special principal, namely the
unauthorized one. Zope3 should have a principal that can't be removed that
is used for unauthorized logins, and there should be a "Viewer" role, that
the anonymous principal is added to by default.

##############
# Permissions
##############

A permission is a token that is used as a requirement for an operation.
Principals retain a certain set of permissions that allow the principal to
carry out a certain set of functions.

Zope systems with many products installed tend to have a lot of permissions.
These need to be grouped to make the UI more usable. I can see four types of
groups: Subsystem, action and object.

The subsystem could be "Zope" for the products that come with Zope core, and
"Formulator", for those permissions, "Easy Publisher" for all the ones we
send with our CM system, and so on. Action would be things like add, delete,
view, send or any verb like that, and object would of course be a specific
type of object, or a group of objects.

There could also be in the Zope core, base permissions like "manage" and
"view" that can be used for the lazy programmers who doesn't feel like
setting up own permissions for their objects.

That way you could in the user interface group permissions on either
subsystem, action or object, and it would be possible to have buttons to set
all or clear all of the visible settings for a role.

########
# Roles
########

A role is an organizational position.

This definition of role is my own, and quite different from the others that
have been put forward here, but since an organizational position will carry
with it a set of permissions, in practice you end up with the same thing: A
set of permissions.

So why change the definition? This is because this has effects on several
other parts. For example, if you have a CM system where you have both
Authors and Reviewers, where reviewers have to accept an article before it
gets posted on the web, it is not just a matter of setting permissions
right. The system would also need a workflow, where the people responsible
for reviewing should get e-mail notifications when articles are submitted
for review. You will in fact want to create a whole workflow with several
different organizational positions that have different permissions and
should be notified on different events, where a document must flow through
this workflow.

You notice that the roles a user has in the security system are tightly knit
together with a workflow system. In fact, the two are in almost all cases
one and the same. A role is therefore more than a group of permissions; it
is a position in an organization.

### Assigning roles

There is no need to have both global and local roles as in Zope2. All roles
should be local and trickle down a hierarchy, acquisition style. Roles can
be assigned to users of course, but also to user containers, in which case
all users in that container and those containers sub-containers will get
that role. You must also be able to "block out" roles, to make principals
have *less* roles in sub-folders.

With this setup of roles, together with the anonymous principal, there will
actually not be necessary to give one role different permissions in
different locations. Instead you give each role the exact permissions that
role should have, and you assign roles to users and containers differently
in different contexts instead. This would be a vast simplification of the
permission system in Zope.

The amount of roles would probably increase so maybe roles need to be
grouped in some way instead. It should not be called groups, because that
would confuse too many. There are already loads of different groups in my
proposed system. I don't need to mention it more in this text, So I won't
call it anything. Suggestions are welcome.

###########
# Grouping
###########

So far in this suggested system, there are lots of different types of
groups. There is grouping of permissions in different types or permissions,
and grouping of permissions into roles, and also grouping of roles.

You also group users by having them in the same acl_user folder or in the
same container. Both these types of groupings suffer from the same problem:
You can't put people in several groups.

But you are also grouping users when you give them roles in a folder. In
fact, if you have a folder that should only be accessible by a task force in
your company, you are in effect creating a group that includes all the
people that have access to this folder, *even though they may have different
roles*. This is rather important for a couple of reasons. First of all this
group is not necessarily a group of equals. This is something that is often
missing in most permission systems. Secondly, you can create a group that
includes it's own manager, by giving one principal a role that allows the
principal to add and remove people from the group.

This is a big feature of Zope already today, and many people have missed out
in this. It makes it easy to create "secret clubs" for community systems, or
shared folders for company task forces and so on.

But there is some drawbacks to this: Firstly, what if you want the same
group of users to have the same set of roles in another folder. You have to
set them up again, in effect creating a second group that looks just like
the first one. Each time a person needs to be added, it has to be added in
both places. That's not a big problem, but what if it's not two places, but
five, or ten!

So, here comes another important part of this suggested system, and credit
here is due to Johan Carlsson here at Torped. It's his ideas.

There should be workgroups. You set up a workgroup just like you would set
up the local roles for a folder, except that the only thing you would
actually gain access to is the workgroup itself. But, you can then add any
number of workgroups to a Zope folder, and the users in that workgroup would
get the roles they were assigned in the workgroup to that folder.

So, in technical terms a workgroup is macro of role definitions.

When you add a user to the group and give him a Reviewer role, he will get
the Reviewer role at all the folders where the workgroup is added to the
workgroup list.

I envision the groups to be another type of leaves in the user hierarchy to
make it as easy to use as possible. This also means that it is possible to
add more type of objects into the acl_user hierarchy, making it possible to
expand it to a proper directory service if you want to.

#############
# That's it!
#############

Comments and questions are of course extremely welcome. How else will I know
if you read it or not? :-)

########
# Intro
########

Security is a complex subject, and I'm not that good at explaining things
and to make things harder for me, I'm going to start with making a lot of
people angry (as usual):

When thinking about Zope security, one needs to get rid of the frame of mind
one is in when it comes to operating system security. Zope is not an
operating system, and the security should therefore not be designed as if it
were an OS. Also, most here are Unix people, and you therefore tend to think
Unix permission and rights, and I'm sorry, but the Unix permissions/rights
system sucks. It really, really, really sucks. So forget Unix security. Zope
security should not work anything like the Unix permission system does,
because it does nearly everything completely wrong, not to mention the fact
that is regards file security and not security for an object oriented
system.

So, angry yet? OK. Take a deep breath and stop being angry and I'll
continue.

This text attempts to outline how I think a security system for Zope3 should
look like. Some parts are very general and not even Zope specific; some
parts are extremely Zope specific. I hope you don't mind that I mix these
things up completely.

##############
# Definitions
##############

- A principal is an entity that can be authenticated. This is similar
to a user except that we don't require principals to be humans --
they could be programs, or servers, or companies, or aliens,
whatever.

- A permission is a token that is used as a requirement for an
operation. A principal is allowed to carry out an operation
if the principal retains the required permission.

- A role is an organizational position. A principal can have none, one or
several roles in a particular context.

Credit should go where credit is due. The definition for principal is Guido'
s. So is the definition for permission, except that I replaced the mapping
explanation with a more general and abstract one of "retaining" a permission
to do the action.

#############
# Principals
#############

A principal is an entity that can be authenticated. If principals get called
users or accounts in the user-interface is completely unimportant to me.
For this document, I will call them principals since they are not
necessarily users and they are not always accounts.

Principals should have properties like full name and e-mail. Preferably the
set of properties a principal has should be defined in the acl_user folder.

Principals should be created in a hierarchy. This would enable the creation
of X.400 style directories and easier integration with X.400 or LDAP
directories. I'll call the branches of the hierarchy for "containers"
because I can't think of anything better.

Although the acl_user folder will end up with it's own hierarchy there will
still be a need for adding several acl_user folders to a system. The
hierarchy of users will lessen the need for the users to be "additive"
though. The security system will probably only need to traverse until one
acl_user folder is found, (or rather acquire it) instead of continue
looking.

The hierarchical user folder will also in a straight and easy way solve most
grouping problems, but not all. See "Grouping" for further thoughts on that
subject.

### The Anonymous principal

On any web-system there should be one special principal, namely the
unauthorized one. Zope3 should have a principal that can't be removed that
is used for unauthorized logins, and there should be a "Viewer" role, that
the anonymous principal is added to by default.

##############
# Permissions
##############

A permission is a token that is used as a requirement for an operation.
Principals retain a certain set of permissions that allow the principal to
carry out a certain set of functions.

Zope systems with many products installed tend to have a lot of permissions.
These need to be grouped to make the UI more usable. I can see four types of
groups: Subsystem, action and object.

The subsystem could be "Zope" for the products that come with Zope core, and
"Formulator", for those permissions, "Easy Publisher" for all the ones we
send with our CM system, and so on. Action would be things like add, delete,
view, send or any verb like that, and object would of course be a specific
type of object, or a group of objects.

There could also be in the Zope core, base permissions like "manage" and
"view" that can be used for the lazy programmers who doesn't feel like
setting up own permissions for their objects.

That way you could in the user interface group permissions on either
subsystem, action or object, and it would be possible to have buttons to set
all or clear all of the visible settings for a role.

########
# Roles
########

A role is an organizational position.

This definition of role is my own, and quite different from the others that
have been put forward here, but since an organizational position will carry
with it a set of permissions, in practice you end up with the same thing: A
set of permissions.

So why change the definition? This is because this has effects on several
other parts. For example, if you have a CM system where you have both
Authors and Reviewers, where reviewers have to accept an article before it
gets posted on the web, it is not just a matter of setting permissions
right. The system would also need a workflow, where the people responsible
for reviewing should get e-mail notifications when articles are submitted
for review. You will in fact want to create a whole workflow with several
different organizational positions that have different permissions and
should be notified on different events, where a document must flow through
this workflow.

You notice that the roles a user has in the security system are tightly knit
together with a workflow system. In fact, the two are in almost all cases
one and the same. A role is therefore more than a group of permissions; it
is a position in an organization.

### Assigning roles

There is no need to have both global and local roles as in Zope2. All roles
should be local and trickle down a hierarchy, acquisition style. Roles can
be assigned to users of course, but also to user containers, in which case
all users in that container and those containers sub-containers will get
that role. You must also be able to "block out" roles, to make principals
have *less* roles in sub-folders.

With this setup of roles, together with the anonymous principal, there will
actually not be necessary to give one role different permissions in
different locations. Instead you give each role the exact permissions that
role should have, and you assign roles to users and containers differently
in different contexts instead. This would be a vast simplification of the
permission system in Zope.

The amount of roles would probably increase so maybe roles need to be
grouped in some way instead. It should not be called groups, because that
would confuse too many. There are already loads of different groups in my
proposed system. I don't need to mention it more in this text, So I won't
call it anything. Suggestions are welcome.

###########
# Grouping
###########