[Zope3-dev] Initial thoughts on the Zope3 security framework

[Martijn Faassen]

Phillip J. Eby wrote:
[snip]
> I prefer to think of a role as defining a *type of relationship* between a 
> principal and an object, which then implies permissions.  X is 'Manager' of 
> Y, for example.  This is inherently local in nature.  In the SQL and 
> LDAP-based applications I usually work on, roles are *computed*, not 
> stored, using the relationships of the underlying data model.

Can you compute local roles in Zope 2? I need this for a client, so
if you are currently computing local roles from user metadata (from LDAP,
say), I'd like to hear more about how you are accomplishing it.

See also this fishbowl proposal I wrote a while back:

http://dev.zope.org/Wikis/DevSite/Proposals/LocalRolesRevamp

Though this raised some concerns about catalogability of local role
information. I think having groups could make local role information still
catalogability (as it doesn't change unpredictably as would be with
computation). Group membership would be computed in that case.

> Talking about content trees tends to obscure this concept, because the 
> content doesn't usually contain such relationships.  But when you're doing 
> an SQL case tracking system and somebody puts a case in, it's pretty clear 
> that the user object referred to by your "requester" field should be given 
> the role of "Requester" in relation to that case.  This then implies the 
> permissions they should have in relation to that case.
> 
> Clearly, the notion of "group" makes no sense in this context, since the 
> application does not grant permissions to all the people who have ever 
> requested something.  Group is inherently placeless, or else you are 
> talking about different groups.  I would have to refer to the "case X 
> requester group" and the "case Y requester group", not the "requester 
> group".  Role is inherently placeful, in that you must have a role *in 
> relation to something*, even if it's the entire application.

Hm, I hadn't considered this issue. If I understand correctly, you want
computable local roles because sometimes it depends on both (externally
stored) user meta data as well as the object at hand.. And groups can
only do the former.

Is that correct?

> This placefulness is inherently useful for developing complex 
> applications.  Groups can also be useful, in that there are often groups of 
> people to whom you would like to assign a role.  If for example I have a 
> group that represents a department, I can assign them a role of Manager in 
> relation to some set of things.  While it's true I'm "just" mapping from a 
> set of principals to a set of permissions, the indirection is very useful 
> because it allows me to extend or reduce the set of permissions granted to 
> a Manager and have those changes apply whether the role is granted to an 
> individual or a group, manually or programmatically (i.e. through looking 
> at object-to-object relationships).
> 
> 
> >A word on the context-sensitivity.  Any object in the object tree (or
> >graph) *can* override the mapping between roles and permissions (via
> >the security tab in the Zope management interface), and/or the mapping
> >between principals and roles (via the "local roles" link in the
> >security tab).  Most objects don't change the mappings, however, and
> >inherit their parent's mappings, and the implementation is optimized
> >for this case.
> 
> Speaking of the implementation, I hope that the local roles kludges do get 
> fixed in Z3.  The Z2 implementation of local roles expects objects to 
> expose a dictionary containing a set of roles for each user.  In many of my 
> applications, computing a complete dictionary or even a complete set of 
> roles for one user could be quite expensive at the SQL level, but a check 
> against a single role or a set of specified roles is relatively cheap.

I reached the same conclusion. See also these interfaces:

http://dev.zope.org/Wikis/DevSite/Proposals/LocalRolesInterface

(which probably are overly simplistic, but stil)

> In order to make these cases work well I essentially had to monkeypatch 
> Zope 2 with an altered local roles API; information about that patch has 
> been sitting dead in the fishbowl for about 9 months now.

Where, where? I need this. :)

> In essence it 
> makes Zope ask "hasRole"-type questions instead of "getRole"-type 
> questions.  There's really no reason (at least in Zope 2) that the security 
> machinery needs to know all the roles a principal has, even against a 
> particular object.  It needs only to confirm whether the principal has one 
> of the roles that supply the permission needed for the current access 
> attempt.

Oh, right, so my interfaces are deficient already; I didn't have a 
'hasRole' defined yet. :)

How would you respond to the issue that this would be hard to catalog?
Right now with the fixed roles dictionary CMF (I believe) is using this
to catalog things. If you have computed local roles, this is impossible.
See also Shane's messages earlier to the list; he seems to have decided
this catalogability is less important, but he may change his mind when he
discovers what you have in mind. :)

[snip] 
> Anyway, this is why it's important (IMHO) for roles to stay around, and for 
> the API to change slightly in relation to role checks.  It should never be 
> necessary for the security machinery to ask for a complete list of 
> roles.  The scheme above still allows caching of roles and permissions to 
> take place, it just may require multiple accesses before a complete cache 
> is built.

You don't mean catalog -style caching here though, do you? What if I want
to ask the catalog 'give me all objecst that I have the role 'Foo' for'?
While I wouldn't mourn if this isn't possible, others might..

Very interesting input indeed!

Regards,

Martijn