[Zope3-dev] Security Model

[kapil thangavelu]

As an additional point of comparison I'd like to go point out the openacs
(4+) security model, as I've found it to be simple, elegant, and flexible.

Its a relational model, but I'll sketch it out with some python code..

class principal: pass

class user(principal): pass

class group(principal):
   """ contains a set of principals """

with these primitives its possible to do most forms of organizational
modeling. 

(the oacs code & documentation uses the word party for principal)



the oacs permission model is based on a multiroot hierarchical set of
permissions, so a particular product might have the following 'leaf'
permissions

Wiki Edit
Wiki Add
Wiki Delete

and then a Wiki Admin permission which would have those permissions bound as
children to it and which itself could be bound as a child to a higher level
admin permission. this greatly simplifies permission management as compared
to the flat z2 permission list.

(the oacs code & documentation uses the word privilege for permission)



the binding of the permission model to the organizational model takes place
via granting permissions to principals in the contexts of objects

def grant_permission( principal_id, permission_id, object_id): pass
and security checks via
def security_check( permission_id, principal_id=None, object_id=None): pass
where optional args are gathered from context.

so basically the complexity for the developer boils down to a single mapping
which encompasses the additional flexibility of groups, permission
hierarchy, and local contexts. openacs structures objects in a hierarchy
similar to zope so granting a permission on a container carries that grant
via containment to its children. something else to note, is that in effect
all grants are local to a context.

I think this is what shane is getting at with role inheritance, ie. a
simplification of the mapping structures in favor of hierarchy, and I think
its definitely of strong benefit.

-kapil

references
http://openacs.org/doc/openacs-4-6-3/permissions-requirements.html
http://openacs.org/doc/openacs-4-6-3/permissions-design.html



On 12/4/03 10:39 PM, "Shane Hathaway" <shane at zope.com> wrote:

> I did not realize until today how similar Zope's security
> infrastructure is to that of Oracle.  I find that encouraging, since
> Oracle has fulfilled the needs of a diverse audience for a long time.
> Zope's permissions are like Oracle's privileges and Zope's roles are
> like Oracle's roles.
> 
> Zope lacks a very neat feature, though: in Oracle, you can grant a
> role to other roles.  I don't think this capability is yet planned for
> Zope 3.  Roles that support inheritance could be an excellent way to
> simplify security.  We would get to use the same machinery for roles,
> groups, and workgroups.  I'll explain how.  If you're in a hurry, skip
> to the last paragraph.
> 
> Many of Zope 2's security abstractions are fundamentally the same kind
> of abstraction.  Users map to roles, roles map to permissions, and
> permissions map to methods.  Every Zope object has the opportunity to
> influence these mappings.  To check access to some method, the
> security policy follows the security mappings as they appear in the
> context of the thing being accessed.  If there is any contiguous chain
> in the links from the user to the method, access is granted.
> 
> So Zope 2 has three security mappings, which is good for a lot of
> people, but three is a fishy number.  Some people might need more
> abstractions, and some less.  Hence Zope 3 introduces new mappings to
> solve that problem: you can assign to users to groups, and groups to
> roles, yielding 4 mappings.  Or you can map users (or groups) directly
> to permissions, yielding 2 mappings.  For kicks, you can map users to
> groups to permissions, yielding 3 mappings in a different layout.  And
> to make things really interesting, there are also permission
> categories (or whatever they are called), letting you stretch out to 5
> mappings.  The concept of workgroups, as I understand it, would add
> yet another mapping.
> 
> All of these mappings seem to do the same thing--they form links in
> the chain from user to method.  The only differences I can identify
> from an implementation perspective are that some are global rather
> than context-dependent, and that they are managed by different people.
> The mapping from permission to method is managed by software
> developers rather than site managers, for instance.
> 
> If you add inheritance to any one of those mappings, that mapping can
> fulfill the purpose of other mappings.  For example, if the user 'Joe'
> maps to the group 'Managers', and the group 'Managers' maps to the
> role 'Editor', you could equally model that by replacing groups with
> roles and mapping 'Joe' to the role 'Managers' and the role 'Managers'
> to 'Editor'.  Note that a lot of people tried to use roles as groups
> in Zope 2, but this generally failed because roles could not inherit
> from other roles.  The chain still only had three mappings.
> 
> Introducing inheritance lets you make the chain as long as you want.
> It would allow great flexibility while reducing the number of concepts
> we have to keep track of.  Site managers would be able to make their
> security mapping chain as long as they want, while Zope 3's code would
> only need to be concerned with the abstract concept of mapping one
> security moniker to another security moniker.
> 
> I see two strategies for inventing a user interface based on these
> concepts.  We could call everything managed by site managers "roles".
> I presume this is basically the route Oracle takes.  What would be
> much cooler would be to let site managers define their own security
> nomenclature.  When you add a security moniker like 'Editor', you
> would also select what kind of moniker it is: a role, a group, a
> workgroup, a privilege, or whatever moniker types you've set up
> beforehand.  On a different form, you could map that moniker to users,
> permissions, or other monikers.
> 
> In conclusion, I think we can unify a lot of Zope's security concepts
> and push the differences between roles, groups, and workgroups into
> the user interface.  I suspect that supporting this model would go
> beyond simply replacing the security policy.  On the other hand, the
> new flexibility would reduce the need to ever replace the security
> policy.  I also think it would reduce the complexity of Zope 3.
> 
> Shane
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev
> 
>