There are some issues with describing a group as an attribute of a user if
one is speaking about physical implementation. To support some operations it
is useful to think of a group as an entity unto itself. Group membership
does not seem to be the same type of thing as say "hair color", which is
indeed an attribute of an individual.
I think the distinction you make about policy assignment is useful.
On a slightly different tack, here is a comment extracted from some Ponder
docs:
"A role is thus a special case of a group, in which all the policies have
the same subject."
This would imply that although roles are useful, one never has to reference
a role from a policy. One can simply reference the group which has a one to
one mapping with the named role. This is not inconsistent with my first
statement:
"For all roles R, there exists a group G such that all members M of G have
role R."
> -----Original Message-----
> From: bill parducci [mailto:]
> Sent: Wednesday, July 25, 2001 3:59 PM
> To: ''
> Subject: Re: Groups vs. Roles
>
>
> for my own edification, i would like to take a shot at this in lay
> terms...
>
> first, i believe that the discussion arose in response to a
> statement/question regarding groups being the same thing as
> roles. i see
> the fundamental difference as this:
>
> groups identify who you ARE, roles describe what you [can] DO.
> therefore, a group is an attribute of a 'user' (or group),
> while a role
> is a collection of policies that are applied to a user.
> policies are not
> assigned directly to a user; by 'assigning' a policy to a
> user, you are
> in actuality assigning a policy to the role that is applied the user,
> either explicitly (via a discretely defined role assigned to
> a user) or
> implicitly (via the unique, unstated role assigned to a user for such
> reference).
>
> does this make sense?
>
> b
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
