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

[Shane Hathaway]

Martijn Faassen wrote:

> Shane Hathaway wrote:
> 
>>>Yes, that's correct. There has been some talk recently about making them 
>>>more
>>>centralized for reasons of making them easier to catalog, but nothing
>>>yet has come out of that. And I rather like the principle of having each
>>>branch of the tree be a tree by itself in Zope. Even so, perhaps Shane
>>>should in a word about his catologing use case .
>>>
>>I've had some more thoughts on that--it occurred to me that the catalog 
>>actually could take over the knowledge of local roles, and could use any 
>>strategy it likes, since it is after all an object index.
>>
> 
> So there would be no local role information anywhere in the tree, just
> in the catalog, and the trees itself can query this local role core service
> to determine whether a user has permissions or not.
> 
> Or do you mean we simply catalog the local role information, and we have
> a catalog that uses something like path indexes to determine whether someone
> has access?


Okay, I'll be more specific.  Let's say local roles can change at any 
point and there isn't a quick way to discover local role mappings 
throughout the site.  (That's the situation today.)  We can still 
perform a catalog query that limits the user to what they are allowed to 
see, in a way that only the catalog has to know about.

(Thinking aloud) the old problem is that we have to be able to feed all 
the user's role mappings, in any place, into the query.  So we have to 
be able to map users to a table of placeful roles before performing the 
query.  This table maps user ids to placeful roles.  We can gather this 
info at indexing time by scanning the acquired local roles for 
user->role mappings.  Every time an object is indexed we'll have to scan 
for these local roles and update the placeful roles table.

Hmm, I hope that made sense.  It seems like it would work, but there's 
still an issue.  If you change local role mappings anywhere, you have to 
recatalog something in that place for the local roles to show up in the 
catalog.  It wouldn't be hard to make the local roles management UI 
aware of the catalog, though.

At least it would be better than the current situation, where every time 
a user is added or any role is changed for any user, you might as well 
rebuild the whole catalog.

OTOH it keeps us from having to change the security architecture just to 
make searching work right, which is definitely a good thing.

>>In any case, I think I'll back down on this issue.
> 
> Hm, what're you backing down on? :)


I've been pushing to make it possible to quickly gather local roles so 
that searching will work better.  But now I think the problem can be 
solved by the catalog implementation rather than the security architecture.

>>Centrally manageable security, OTOH, seems like a good goal anyway.
> 
> Centrally *manageable* yes, but I'd like every subtree to be as independent
> at the same time, which is another good goal. What I take as the center
> where I'm managing from should ideally be any branch of the tree I pick..

Sounds right.

Shane