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

[Phillip J. Eby]

At 04:09 PM 12/14/01 +0100, Martijn Faassen wrote:
>Phillip J. Eby wrote:
> > 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?

Something like that.


> > 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. :)

It's in LoginManager/LoginManager.py, in a clearly marked section called 
"Local Roles Patch".  :)



>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..


Catalogability of roles isn't a primary concern for me, but I think this 
can adequately be addressed in the new religion through interface 
declarations.  If my object doesn't declare an interface for getting such 
local roles, then that stuff won't be cataloged, which is just fine for 
what I'm doing.  If I need to find things to which I have a particular 
role, I can do that just fine with SQL; no need to go through a catalog.

All I'm saying is, the *security* machinery should not rely on getRole-type 
queries, as opposed to hasRole-type queries.  If a cataloging component 
wants another interface, that's just fine by me -- I don't have to use it.  :)