Let's take my frustrations with Zope declarative security and throw some fuel on this fire.
1) The Zope security model doesn't have any layers. By this I mean a notion where there is a cascading set of rules, whereupon the system doesn't have one and only one place to look to grant rights. For example: the system default policy, the group default policy, the entity default policy, the object policy, the entity override policy, the group override policy, the system override policy. So, I might in my system default policy say "deny * to all" but in my group default policy say "grant * to all" (where ALL is all members of my group)... but then in my system override policy I could say "deny * to blocked_user" to lock out a specific user. In a large system, the end user may be able to only set certain policies, which can be supplemented by the default rules and overriden by a override policies.
2) The Zope model doesn't have any way to provide for computed roles. Imagine a simple system with a hierarchial set of folders and simple roles. To provide n * m role assignment (ie, user K is an Author in the Foo folder) one has to visit every single stupid folder and set local roles on it. If there are lots of users, you can use GRUF in Plone and assign a group to the role to consolidate permission setting to one spot, but you still end up saying local role Author = group_foo_authors on the Foo folder. There is no facility to evaluate an expression to determine the permission (ie, grant update where user_groups contains "author" and user_groups contains "foo")
This latter part tends to be frustrating when you get the "oh, the Zope security model is very flexible" tossed back in your teeth. True, its flexible, but it isnt easily ADMINISTERED in this instance without writing custom components or a custom security policy. Neither is particularly attractive.
Oh, and...
Posted bymattat
2005-07-21 10:20 AM
Comment #2 above should be extended by saying in many cases, objects should have additional security metadata associated with them, so you can say things like "allow update when user has the Reviewer role and they are a member of this object's primary security group." For example, the Foo folder may be associated with the "Foo_association" security group, and thus I want to apply "Foo_association" rules to it, NOT go pollinate every f*cking possible object and slam on new local roles. Some of that can be handles as guards on workflow transitions, but the Zope model is just not designed to accomodate anything more than a fairly simple permission mapping.
1) The Zope security model doesn't have any layers. By this I mean a notion where there is a cascading set of rules, whereupon the system doesn't have one and only one place to look to grant rights. For example: the system default policy, the group default policy, the entity default policy, the object policy, the entity override policy, the group override policy, the system override policy. So, I might in my system default policy say "deny * to all" but in my group default policy say "grant * to all" (where ALL is all members of my group)... but then in my system override policy I could say "deny * to blocked_user" to lock out a specific user. In a large system, the end user may be able to only set certain policies, which can be supplemented by the default rules and overriden by a override policies.
2) The Zope model doesn't have any way to provide for computed roles. Imagine a simple system with a hierarchial set of folders and simple roles. To provide n * m role assignment (ie, user K is an Author in the Foo folder) one has to visit every single stupid folder and set local roles on it. If there are lots of users, you can use GRUF in Plone and assign a group to the role to consolidate permission setting to one spot, but you still end up saying local role Author = group_foo_authors on the Foo folder. There is no facility to evaluate an expression to determine the permission (ie, grant update where user_groups contains "author" and user_groups contains "foo")
This latter part tends to be frustrating when you get the "oh, the Zope security model is very flexible" tossed back in your teeth. True, its flexible, but it isnt easily ADMINISTERED in this instance without writing custom components or a custom security policy. Neither is particularly attractive.