[Zope3-dev] Re: a note on groups and roles

[Phillip J. Eby]

At 12:13 PM 3/28/02 -0500, Jeremy Hylton wrote:
> >>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>   >> How would this distinction have an impact on implementation?
>
>   PJE> Because a "set of permissions" carries no implication that it
>   PJE> is the application that grants that set to a principal, rather
>   PJE> than the infrastructure doing so.
>
>I'm not sure I understand what you mean.  The application provides
>mechanism, and the admin using the application uses that mechanism to
>define policy, right?

No.  The application grants the permissions.


>  I think this is what you mean, but I'm not sure
>because you say applications grants permissions to principal.  The
>application shouldn't actually grant permissions; it should define the
>permissions that an admin can assign to principals.

Nope.  Please go back and read my examples regarding project management and 
trouble ticketing.  It would be insane to have an administrator define each 
person's permissions in relation to each trouble ticket in an application, 
for example.


>   PJE> If we call a "set of permissions" a "SOP", then the
>   PJE> requirements I have regarding them are:
>
>   PJE> 1. Allow individual application objects to grant SOPs to
>   PJE>    principals
>
>Well, maybe I'm not interpreting you correctly.  Can you be specific
>about how an application grants SOPs to a principal?  How would it
>know what principal to grant a permission to?

 From application-specific data, such as the "requester" field on a trouble 
ticket.


>   PJE> 2. Zope should ask application objects *only* for SOP's needed
>   PJE>    by the
>   PJE> current principal to carry out their immediate intentions
>
>Hmmm... I think I like where you're going, but this sentence is hard
>to unpack.  The traditional notion of "role," as I understand it, is
>a mechanism for a principal to limit the set of permissions it uses to
>perform an operation.  Example:  A sys admin invokes method foo() with
>the "print server" role, which means that foo() will only have
>permissions related to administration of the print server.  Is that
>your goal here?

No.  I'm specifically addressing a problem in Zope 2's "local roles" 
interface, which asked objects to tell Zope *all* SOP's granted to a user, 
whether they were needed or not.  In complex applications, where each role 
may be computed by various database lookups, this does not scale well.


>If so, shouldn't the principal be saying what role it wants to use?
>If it's the application, then the application could lie to the user
>and trick her into using the wrong role.

We have a different notion of application here.  My realm of applications 
are *trusted* applications.  A "site" in my environment consists solely of 
code written by me and my team; it is as "trusted" as it can be.  We don't 
need to "trick" anyone, because we are the ones who write the code that is 
going to do whatever it is we give them permission to do.



>   PJE> 3. SOP's are definable by applications for use within their
>   PJE>    "placeful"
>   PJE> space, without conflict with SOP's in use in other spaces
>
>I don't think I understand this one at all :-(.  Do you mean merely
>that if permissions are named, that there is a mechanism to avoid
>namespace collisions?

I believe that would be sufficient.  I don't recall right off what I was 
saying #3 in response to.