[Zope3-dev] a note on groups and roles

[Jeremy Hylton]

>>>>> "LR" == Lennart Regebro <lennart@torped.se> writes:

  LR> From: "Jeremy Hylton" <jeremy@zope.com>
  >> 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.

  LR> Well, currently Zope doesn't have any groups at all, so what the
  LR> Zope philosophy in that case is a bit fuzzy. :-) But yes, a
  LR> group would be a set ofprincipals.

Groups are a big help, and we can already use roles to implement
"groups," so they exist in some sense.  (Is it possible to assign one
role to another role?  A SuperDeveloper had developer and super
roles?)

  >> Groups and roles serve the same purpose.

  LR> Well, not really. But if groups do nothing more than group
  LR> principals, then groups are only a way to make assignments of
  LR> one principal to several roles quicker.

Quick has nothing to do with it.  The hierarchy promotes modularity in
security administration and makes it easier to reason about the policy.

  LR> Your group' scheme may simplify the implementation of groups and
  LR> roles, but infortunately it doesn't make the security any easier
  LR> to explain to outsiders, because you then end up with two
  LR> different types of groups' that act slightly different, or you'd
  LR> end up with a concept of group' that is highly abstract.

I meant, in particular, explaining it to someone who is familiar with
standard security terminology.

What we're left with is one concept group, that can be used for
multiple purposes.  For a user manual, it would be helpful to describe
several different uses of groups.

  LR> end up with a concept of group' that is highly abstract.  I
  LR> don't think people will generally understand when you say that
  LR> "a group' speaks for principals". I myself had to think about
  LR> it. Abstraction can be a good thing, especially if it leads to
  LR> higher functionality or flexibility but it doesn't in this case,
  LR> it's just a nother way of looking or implementing grous and
  LR> roles.

Only the implementors need to think about speaks for or speaks as.
It's important for the implementation to have as few concepts as
possible, since it keeps the implementation simple.  The user
interface / policy language for expressing things *might* introduce
several concepts that map onto groups in the implementation.

  LR> When this needs to be extended with some kind of "grouping" of
  LR> principals, it's easy to get stuck "how did they do that in
  LR> <insert favourite security system here>". And since most people
  LR> here have used unix or NT, you start thinking of making groups
  LR> of principals, because thats how everybody else is doing
  LR> it. *But*, that doesn't fit well with the innovative roles
  LR> concept.

I'm not sure what the innovate roles concept is :-).  It sounds a lot
like groups, and that's an old idea.  

Jeremy