[Zope3-dev] Re: Certification: Supporting"Residual InformationProtection" in Zope 3

Jim Fulton jim at zope.com
Fri Dec 16 09:59:10 EST 2005


Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martijn Faassen wrote:
> 
>>Roger Ineichen wrote:
>>
>>[Martijn goes into why this might be slow]
>>
>>
>>>Yes you are right. Do you have another idea?
>>
>>
>>A fairly drastic one, unfortunately -- catalog all role and permission
>>assignments and run a query as soon a user is removed.
> 
> 
> CMF does this for local roles, and Jim is already on record as disliking
> it.
> 
> I am pleased with the *result*, which also allows the catalog to filter
> "normal" content results efficiently based on the user's roles (the
> original eason for the index).  OTOH, the *implementation* is grotty.

I don't like the use case very much, but accept that it is valid.
You convinced me one day that this doesn't have to be so bad, especially
if most grants are to groups/roles.  (I've abandoned using roles as a principal
grouping mechanism, but that's a different topic.)

In any case, that's a different data structure than what we need here.

Here, I think the best solution is for the authorization system to store
grants in a centralized data structure of it's own.  This data structure
would be optimized for it's own purposes, not for document searching.
These two use cases want different data structures.

> 
>>Hm, perhaps another idea would involve the timestamp of creation in the
>>userid somewhere, to make the ids unique. Unfortunately I don't see how
>>that would work with external authentication systems such as LDAP, as we
>>don't know when userids are created and removed there.
> 
> 
> The actual ID used by LDAP is a DSN.  Perhaps the authorization system
> could map the DSNs to internally-generated integer ID, which would be
> the only value actually stored in grant records.

Isn't a dsn a string?  That's all we require of a principal id. What
advantage would an integer provide?

In any case, we are left with a more basic problems:

- Someone could be removed from an external user source without
   Zope being aware of it.

- An external system could remove a principal and reused the
   id for a new principal -- again without Zope being aware of it.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list