[Zope3-dev] a note on groups and roles

[Jeremy Hylton]

A conversation with Matt Behrens and Shane Hathaway lead me to write
this note on the difference between groups and roles in Zope
security.  I'd be grateful for comments and criticism.

Jeremy

A note on groups and roles

The current Zope philosophy advocates a distinction between group and
role that is not found in the security literature.  This note argues
that Zope's concepts of group and role both correspond to the
traditional notion of group, and that roles are a separate and useful
concept. 

I believe the current Zope philosophy is this:

    A principal corresponds to a user, e.g. Jeremy.
 
    A group is a set of principals, e.g. Jeremy is in group PythonLabs.

    A role is a collection of permissions, e.g. Developer role has
        permission to do CVS checkins.

A Zope3 security policy is described using these concepts as follows:

    The CheckinPermission is required to commit changes in a CVS
    repository.  (The specific set of permissions depends on the
    application; the set tends to be chosen by the developers, because
    they are responsible for writing code that checks the
    permissions.)

    The Developer role has many permissions, including
    CheckinPermission.  It might also, for example, have the
    ViewCVSLog permission or the CloseBug permission.  A role collects
    a set of permissions.  It is an important use of hierarchy because
    it provides a separation of responsibility for deciding what
    permissions developers should have and who should have them.

    A group is assigned one or more roles, e.g. PythonLabs has the
    Developer role.

    If I try to commit a change, the access control system will allow
    me to make that change because:

    Jeremy is in group PythonLabs, and
    PythonLabs has role Developer, and 
    Developer has CheckinPermission.

We can add extra levels of hierarchy for groups or roles.

    PythonLabs is a member of the ZopeCorp group.

    The TechnicalManager role has the Developer role.

The hierarchies meet each other when a role is assigned to a group.
The reference monitor follows a chain from a principal up through one
or more groups, then down through one or more roles to a permission.
At each step in the chain, the reference monitor must have some
evidence that the security policy allows it.  The policy says that
Jeremy is a member of the PythonLabs group.  The policy says that
PythonLabs has the developer role.  

    This is typically formalized using the "speaks for" relationship.
    One principal can speak for another if the security policy allows
    it.  The existence of a speaks for relationship provides the
    evidence the reference monitor needs for a particular link in the
    chain.  What's interesting is that "speaks for" can describe the
    relationship between principal and group and between group and
    role!

What if we decided that Developer would be a group?  And it would have
a role CVSCommittor?  The chain would be just the same, but there
would be an extra level in the hierarchy.  But we just turned a role
into a group?  Why did that work?

Groups and roles serve the same purpose.  Let's consider a new
definition of group -- I'll spell it group' -- and see if it can
accommodate what we've been doing with groups and roles.

A group' is a principal that speaks for one or more other principals.
A security policy associates permissions with principals.  A request
is allowed if the requesting principal has the necessary permission or
if a principal it speaks for has the permission.

We can accommodate the old definitions by the following conventions:
Permissions are only associated with a special group' called a role.
This is just a convention.  Neither the formal explanation nor the
implementation need to know about this policy, although it would be
simple to implement using a subclass of group'.

Why should we care about a model where group' subsumes group and role?

There are two reasons:

    It simplifies the security architecture, making it simpler to
    reason about and implement.  A security architecture is hard to
    get right, but we increase our chances if it involves the minimum
    number of basic concepts.

    We can communicate more easily with people who are not familiar
    with Zope, because we can use standard terminology.

What's a role'?

Funny you should ask.  The term role -- I'll spell it role' -- is used
in the security literature is used to refer to a mechanism to achieve
the principle of least privilege.  A role' is a way for a principal to
limit the permissions it has.  If you know Unix, it might be helpful
to think of it as a fine-grained setuid.

If a technical manager has two roles' -- Developer and Manager -- he
might want to perform an operation using only one set of permissions.
When we performs a CVS checkin, he performs is using the Developer
role'.  As a result, the access controller only checks his Developer
permissions.

Why might this be important?  One reason is to limit the damage done
by a Trojan horse.  An attacker might trick the manager into running a
program that secretly tries to approve a bogus expense report.  If the
manager ran the program using his Developer role', the Trojan horse
would fail because it didn't have the necessary permission even though
the manager did.

    This concept of role' is formalized using the "speaks as"
    relationship.  It's fundamentally different than speaks for.  One
    extends the permissions of a principal, the other limits them.

Would roles' be useful in Zope?  I expect so, but that's a different
topic.

Where is all this formalized?

B. Lampson, M. Abadi, M. Burrows, and E. Wobber.
Authentication in distributed systems: Theory and practice.
ACM Transaction on Computer Systems: 10, 4 (Nov. 1992), pp. 265-310.
http://research.microsoft.com/lampson/45-AuthenticationTheoryAndPractice/Abstract.html
(Just Google it.)

Lampson has recently written a shorter, less formal paper titled
"Computer Security in the Real World."  It covers some of the same
concepts.
http://research.microsoft.com/lampson/64-SecurityInRealWorld/Abstract.html