[Zope3-dev] My take on Zope3 permissions / security.

[Jim Fulton]

I saw this after I added my definitions to the Glossary.

I agree with most of what you say. I have a few comments:

Lennart Regebro wrote:
> 

...

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

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

I like my definition, which can encompass yours, better.
A role is a responsability. Of course, many organizations 
create positions with responsabilities.  

...

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

I don't think we should mandate much in the way of meta-data. Perhaps we
should suggest and strongly encourage meta-data.

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

I don't understand what you want to use the hierarchies for. Are the
hierarchies only for directory search, or do they imply reuse of
security information?

...

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

I suggest the word "organized" instead.

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

Cool, although I don't see a need for "object" categories. I think subsystems
cover the same idea. From a software-engineering point of view, roles
correspond to "actors".  I'll add both "actors" and "positions" as
additional ways to think about roles in the glossary.
 
...

> ########
> # 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 isn't so different from the current definition of role.

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

Yes
 
> 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.

I think that this is a little string. I do absolutely agree that there
is a connction between workflow and security and that workflow should
build on roles.

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

I can see this as a possible policy. You are essentially defining a
group as the contents of a principal container.

> You must also be able to "block out" roles, to make principals
> have *less* roles in sub-folders.

Yes. We plan to provide the ability to make denial security statements
that will encompass this.
 
> 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.

I think this is a workable policy, but I don't think that it will be
applicable to everyone's application.

> The amount of roles would probably increase so maybe roles need to be
> grouped in some way instead.

I would be worried if this became necessary.

> 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 should use the verb "organize" and noun "category" rather than
"group". The term "group" has a specific and pretty standard meaning.

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

A "group" is a principal that is a collection of other primncipals,
possibly including other 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.

I think what you want can be achieved with groups.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org