[Zope3-dev] a note on groups and roles

[Brian Lloyd]

> I'd like to think about this more.  The notion of a "local role" is
> interesting, but I wonder if it isn't more appropriate to talk about a
> "local group."  *Or* a place as a principal that delegates to a user
> for requests "in the context of the folder."  (The last part in quotes
> because I'm not sure I understand it yet :-).
> 
> In other words -- a group is about adding permissions, a role is about
> taking them away.

It sounds like we are really at a point where we should 
start developing a set of use cases to clarify things 
and validate the many points brought up in this 
discussion.

We might actually want to start with a set of common 
"scenarios" with possibly several sets of use cases that 
could achieve the goal of the scenario. If nothing else, 
this can be the seed of a document that captures the 
"recommended" way to apply different security policies. 

For example:

  Actor: Site Administrator

  Goal:  Let the new editor we just hired get to work
         without knowing every detail of site policy

  Scenario:
    SA's company just hired a new editor. Editors are  
    responsible for producing and reviewing content in 
    various areas of the website. The privileges of an 
    editor are different in different areas of the site
    (for example should be able to review, but not edit, 
    documents in the legal docs area of the site).

    The SA need to give the new editor appropriate privileges 
    on the site so he can get to work. The site is quite 
    large, with varying access policies depending on the 
    group that has oversight of a particular area.

    The SA is a busy guy, and he is not necessarily very 
    familiar (nor does he want to be) with the details of 
    what editors can or can't do in the legal docs area of 
    the site (that is a policy matter that legal takes care 
    of). Nor does he know or care much about the many other 
    areas of the site that editors deal with (and that have 
    their own policies).

  Solution:
    To deal with this, the site is architected in a way that 
    allows the SA to focus on just putting a new employee into 
    an appropriate organizational "group". If he does this, then 
    policies already defined in the site will work correctly.
    
    There are a number of groups that the site architects have 
    defined (such as "editors", "marketing", "legal", etc.). 
    These groups organize users along organizational boundaries. 
    When a new employee comes on, he is added to the appropriate 
    organizational group or groups.

    The owners of the various site areas have implemented security 
    policies based on these organizational groups. In the legal docs
    are of the site, for example, a "Legal Reviewer" role has been 
    created that maps to the permissions appropriate for those 
    performing review of legal documents. The maintainers of the 
    legal docs section have also given the role "Legal Reviewer" 
    to the "Editors" group in that area.

    In the Public Relations area of the site, things are a bit 
    different. Editors play a much more active role there, creating 
    much of the site content themselves. In the PR area, a "PR Editor" 
    role has been created that maps to permissions needed to build and 
    maintain content in that area of the site. The "PR Editor" role is 
    given to the "Editors" group here, as well as to the "Marketing" 
    group.

    This approach allows the SA to simply add the new guy to the 
    "Editors" group and he's done. He doesn't need to know or care 
    who has what privilege in different areas of the site.
 

I'm not sure what the best way to tie these into discrete 
use cases is, but I think that having some coverage of the 
common scenarios as a first step would help a lot in clarifying 
things.


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716       
Zope Corporation   http://www.zope.com