[Zope3-dev] Re: role (contextual) services?l

Jim Fulton jim at zope.com
Mon Apr 5 14:02:19 EDT 2004


Tres Seaver wrote:
> Jim Fulton wrote:
> 

...

>> There was a convincing argument made on this list a while back that
>> it is better *not* to think of groups as principals.  I suggest that
>> we adopt this point of view. (I just updated the glossary entry. :)
>> Then groups would be an artifact only of a particular security policy,
>> independent of authentication service implementations.
> 
> 
> I remember the assertion, but I don't remember being convinced. 
> Certainly groups don't authenticate;  if that is all that a "principal" 
> means, then why did we abandon "user"?

Groups were one of the reasons we abandoned "user".

Some other reasons we abandoned users:

- We wanted to make it possible for a single user to authenticate
   in different ways.

- We wanted to allow certificate authentiaction, where there isn't necessarily
   a "user" behind the certificate.

> For authorization purposes, groups *are* (compound) principals;

Or they represent multiple principals.

 > they
> can be bound (via whatever mechanism the policy supports) to 
> permissions.  The composite pattern is particularly appropriate because 
> groups may contain both users ("leaf" principals) and other groups 
> ("composite" principals).  A security policy which honors groups grants 
> permissions to principals, perhaps directly, or perhaps via an 
> indirection like roles.

I'm not suggesting we don't want groups.  We just don't need to make them
principals. By making them *not* be principals, we get the significant benefit
of not involving authentication services. This, IMO, is a big advantage.

The Zope 3 security model has 4 parts:

- Authentication

- Permission declarations (saying what permissions are required
   to access or modify names)

- Protection, enforcing the permission declarations

- Authorization (aka security policy)

I'd like to keep these as indpendent as possible, which is why
I strongly prefer to make groups soley part of the authorization
system.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org





More information about the Zope3-dev mailing list