[Zope3-dev] questions concerning the security framework

[Sven Schomaker]

OK, first of all thanks for all your answers,

as far as I was able to figure out from the possible solutions
stated here and in zope3-users, there actually seems to be no
way to achieve a higher level of control about the details of attribute
or method access just by means of zcml and the use of the
stock security policy.

While it appears to be a stated goal for the security system to
be highly flexible and comprehensively configurable just through
zcml I feel it lacks some more sophisticated control over the details
of attribute or method access (please correct me if I'm mistaken).

Wouldn't it be somewhat desirable to have the ability to configure
permissions by means of zcml that somehow considers more details
of method calls or attribute access such as state (actual values)
and/or type of attributes/method parameters?

I'm aware of this would probably be a major enhancement to the
system, but it might be of some broader interest. Or maybe I'm just
fully mistaken and got a skew view on this issue. Maybe anyone can
tell me why did one decide for a somewhat "plain" security policy?

(Admittedly I did not consider any use cases beyond mine, so this
might not be of such broad interest as I fancy at first.)

The next question that arises is about the workflow and how object
state might be related to permissions on attribute/method access.

As I was able to figure out from the postings it seems to be a common
idea (or approach) to dynamically assign and revoke permissions (or
interfaces that are bound to specific permissions) to a role or class,
but for me this seems a bit cumbersome.

Wouldn't it be nice to have a cleaner and more customer-friendly
approach to bind permissions to an object state and have it built in
more natively into the stock security policy?

At least for me it seems to be a common case to have a workflow
(or at least a common kind of state transition) involved when handling
content and thus it might be useful to have the ability to bind state and
access permissions together build into z3.

So thats for now and I welcome any thoughts on it.

Thanks + Greetings

Sven

PS: Maybe this has been discussed before or is all rubbish anyway.
If so please forgive me and just point me to the appropriate site
to be enlightened.



Garrett Smith wrote:

>Sven Schomaker wrote:
>  
>
>>Since the message board is a container and the
>>framework uses __setitem__ to add new objects
>>to the container, how would one distinguish the
>>permissions to add an announcement from the
>>permission to add a topic with zcml or with
>>explicit python coding.
>>    
>>
>
>You can attach a precondition to your container's schema's __setitem__
>method. (See zope.app.container.constraints.IItemTypePrecondition.)
>
>In the precondition '__call__' method, you can use
>zope.security.checkPermission to test whether the current user
>(principal) has permission to access the object being added via
>__setitem__. In the precondition 'factory' method, you can check
>permission on the object factory (before it's created).
>
>This approach has the benefit of filtering out object types the user
>can't add from the default Add UI.
> 
>  
>
>>Another question is about bringing the workflow
>>into the security system. As I was able to determine
>>there is the possibility to configure permissions
>>on causing state transitions using zcml. Thats fine
>>so far, but how would one restrict e.g. the ability
>>to modify messages once they have been submitted,
>>i.e. bind the permissions on content-objects to a
>>specific workflow state?
>>    
>>
>
>I believe the way to handle this is to modify principal or role
>permissions for the object whenever a workflow state changes. E.g. when
>the state changes to 'Closed', you would remove the 'zope.ManageContent'
>permission for the ordinary user role, but preserve it for managers.
>
>I'm not familiar with the current state of workflow (I suppose pun
>intended), but I think this is the approach one would take.
>
>  
>
>>The next question is whether there is something
>>like a build in role for the owner of an object or
>>if there is the notion of ownership at all? For me
>>this seems to be necessary if one would only grant
>>permissions to modify an object if he/she is the owner
>>of that particular object as it has been done in z2.
>>    
>>
>
>There's no build-in notion of 'owner' in Zope3. One could implement such
>a concept in their application using workflow rules. E.g. you might
>assign a principal role of 'yourapp.Owner' for an object when it's first
>created. Depending on your application, that role might be transferable
>to another principal, or shared among more than one principal, etc.
>
>  
>
>>And last but not least is there the concept of local
>>roles like it has been in z2?
>>    
>>
>
>I believe this is being handled (or will be handled) with the pluggable
>authenticaion service (PAS). I'm not sure what the status of this is.
>
> -- Garrett
>  
>