[Zope3-dev] Zope3 security suggestion

[Lennart Regebro]

I've posted this before, but since the same discussion now pops up again,
I'll post it again (with some changes prompted by the comments I got fom
Shane and Jim. Thanks for those.).

I'm also adding this to the WIKI.
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AccessContr
olProposal

########
# 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  responsability. It could also be thought of as "actors". What
do I need to act as, I need to act as a manager, so, therefore Manager
should be a role. A principal can have none, one or several roles in a
particular context.

Credit is due: I didn't make these up my self, it's Guido and Jim mostly.
:-)

#############
# 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 that is what Zope
people tend to call them.

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,
so that each organization can select what meta data they need.

### 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 organized to make the UI more usable. I can see three 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 a responsability within an organisation.
This is implemented as roles being a set of permissions. This grouping of
permissions is needed as the amount of permissions increase with the amount
of products installed ina Zope system.

### 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
###########

Many people confuse roles and groups. I think this be due to that people
expect groups, don't find any, and then when they find roles, they think
"oh, they are called roles here". No, they are not. :-)

It is possible to use roles as if they were groups, but another way of
"grouping" people in Zope is to givegive 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. 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.

Workgroups
==========
I'm calling this workgroups to distinguish it from groups and groups'. :-)

A workgroup is a set of principals. But you set up a workgroup just like you
would set up the local roles for a folder, ie, you do not only assign users
to the workgroup, *you also assign roles to them within this workgroup*.

When setting up a workgroup the members of it don't get access to anything
but 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.

That way you still get the grouping and indirection that you get from other
groups, but you also get a greater automatic granularity in that grouping.


In technical terms
==================
So, in technical terms a workgroup is macro of role definitions. When you
add a user to the workgroup 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. The workgroup "Boss" will get the "Boss" role in all the
places where this workgroup is added.

With normal grouping, you typically have one group per department, and give
that department access to a couple of parts of the database. Then you have a
group of the Bosses that have more access. But usually this means that all
the Bosses have Boss access everywhere where bosses have access, which is
not necessarily what you want.
To get around that, you would have to split the departments into loads of
groups, one group for each role in each department. Workgroups solve that.

As related to real life
=======================
The nice thing with roles is that it maps very nicely into real life. In an
organisation a person have one or several roles in each area, and in these
roles he/she needs to do certain things. This maps perfectly to have
principal having one or several roles which gives the principal a set of
permissions.

In any big organisation there are different types of groups, like
departments, teams, taskforces. But very seldom does everybody in that group
have the same role. In each department there are a department boss. The
teams have team leaders, and so on. The workgroups concept is therefore a
much better match for how organisation is done in reality. You have some
sort of group, where different people have different roles within that
group.

This workgroups concept take the grouping of principals one step further,
and extends on the Zopes brilliant roles system, rather than patch over it.
It is not just one level of indirection, but an orthogonal extention of
Zopes security system to match larger organisational structures.



#########
# Hierarchies
#########

Another way of grouping is putting principals in hierarchies. It has rather
big effects, so I have put it into the end of this proposal since it is
rather separate. I'll call the branches of the hierarchy for "containers"
because I can't think of anything better.

Hierarchies would enable the creation of X.400 style directories and easier
integration with X.400 or LDAP directories. It would also automatically
create a group system of sorts, since each container could be used as a
workgroup. It would be easier to manage large sets of users.

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.

It would also mean that you may have to log in with
denmark.copenhagen.johnson or sweden.stockholm.regebro instead of your
ordinary usernames, but there are several ways to simplify that.

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

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