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 ########### 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? :-)