[Zope3-dev] RFC: Unification of requests and security contexts through Use

[Phillip J. Eby]

At 10:38 AM 1/17/04 -0500, Jim Fulton wrote:
>Currently, the use is primarily a collection of actors.  I think that this 
>provides
>sufficient value, but I think that the concept is a bit bigger than than and
>I think, at least in some applications, the use objects will be more than just
>collections of actors.  For example, they might manage additional information,
>like the location of activity (in Zope) or auditing information, such as 
>information
>about when actors joined and left the use.
>
>The participation is important because we often care about the way actors 
>interact
>with the system. For example, wrt security, we might treat an actor that 
>participates
>via HTTP differently than an actor that participates vie HTTPS, or CORBA 
>or an actor
>that participates via code authorship.

Okay, I think the UML diagram in the proposal is misleading, then.  It 
doesn't show this
relationship.  It needs to be more like:


     Use <>-- Participation --- Actor --- Principal

That is, if I understand what you're saying, the use needs to know the 
participation, which represents a relationship to an actor, that represents 
principals.

At that point it seems to me that either "Use" or "participation" could 
then take on the responsibilities of authorization and access to permission 
declarations, rather than being a "data object" that gets passed to 
something else to do the work.

The thing that keeps confusing me in all this is that I can't visualize any 
concrete use cases for multi-actor participation that aren't better served 
by a model specifically created for that kind of interaction.  I don't see 
how making an abstract collection of participations or actors in a use is 
really useful for such things, as compared to writing a *specific* use 
class for that scenario that has typed relationships of e.g. author, user, 
whatever.  E.g.

class ChatUse:

     # Various collections of participations:
     moderators = ...
     panelMembers = ...
     spectators = ...

versus just having a bunch of "actors" or "participations" in a general 
lump.  Perhaps part of the problem comes from the pluggable policy model, 
and the existence of ISecurityManager.  It would be easier, I think, to 
simply have one and only one object responsible for doing 
checkPermission(permission,object), and to drop the execution stack concept 
out of the security system.  If that object is the Use, then it may 
implement appropriate policy directly within itself, with direct access to 
the specific kinds of knowledge needed for that kind of Use.

That is, instead of having a "security manager" that keeps a stack of 
executables and policies, just have uses be able to check permissions 
themselves.  If they want to delegate this to a previous (containing) use, 
fine.  If an executable wants to set up a new policy, let it create a new 
use that delegates to the old one as appropriate, and pass that new use 
down to anything it calls.  The explicit stack is replaced by a delegation 
chain (that doesn't require try/finally to ensure things get popped) and is 
threading-independent.

If I understand correctly, this would do away with the need for 
ISecurityManager, ISecurityManagement, ISecurityManagementSetup, 
ISecurityContext, and ISecurityPolicy, except perhaps in zope.app as part 
of Zope 2 compatibility.