[Zope-Coders] please review LocalRolesRevamp

[Shane Hathaway]

Martijn Faassen wrote:

> Hi there,
> 
> I'm not entirely sure if I should be posting this to zope-coders
> or zope-dev; I'd like to avoid lots of crossposts to both lists
> however, so I'm trying this list first.
> 
> I've just added a proposal to the fishbowl to improve Zope's
> local roles system. This because I needed computed local roles,
> and I'd like the local roles UI to become more scalable over
> large amounts of users as well. 
> 
> While the LocalRolesRevamp proposal is still officially in
> EditorialReviewState and not in TechnicalReviewState, but
> I'm just going for technical review anyway. If there's something
> wrong I'll just assume the editor will punish me, or you all will
> yell at me. :)
> 
> Anyway, here's the link:
> 
> http://dev.zope.org/Wikis/DevSite/Proposals/LocalRolesRevamp

I have a different viewpoint on this that I hope you might consider.

One of the nice features of CMF is that it filters search results based 
on what you're allowed to view.  It does this by cataloging the list of 
roles that are allowed to access the object.  Then when you perform a 
search it injects a filter into the query that limits what you see based 
on your roles.

Simplifying for a moment, say the cataloged field is called 
"allowedRoles", you have an object "A", and the roles allowed to access 
"A" are ["Manager", "Reviewer"].  When user "R", who has the roles 
"Reviewer" and "Authenticated", performs a search, the catalog will add 
to the query a filter that matches any of the roles ["Reviewer", 
"Authenticated"].  Object "A" matches, so if the other criteria match as 
well, it will be returned.

This gets messy when you consider local roles.  Today, the CMF catalog 
has an "allowedRolesAndUsers" field.  It contains not only the global 
roles that are allowed to access the object, but also the IDs of users 
who are allowed to access it based on their local roles (prefixed by 
"user:").  When a user performs a search, the filter that is added to 
the query contains, in addition to the list of the user's roles, the ID 
of the user, prefixed by "user:".

If you think about it, this strategy works, but has a couple of lurking 
problems.  They might be major problems for some people.

   - You have to be able to precompute the entire list of users who can 
access an object.  That might not be possible in some environments. (LDAP?)

   - If you use local roles to set up areas for workgroups, every object 
stored in the workgroup folder is going to have to be cataloged with the 
name of every user who can access it.  That could be a scalability issue 
if there are a lot of people in the workgroup and they manage a lot of 
objects.

Another strategy for the CMF catalog would be to use a "qualifiedRoles" 
field in the catalog instead of "allowedRolesAndUsers".  Roles would be 
prefixed with the physical path of the role.  So if object "A" is 
accessible to the global roles "Reviewer" and "Manager" as well as the 
local role "WorkgroupMember" defined in "/workgroups/hr", object "A" 
might be cataloged with qualifiedRoles set to 
["/workgroups/hr:WorkgroupMember", "/:Reviewer", "/:Manager"].

We could do this if it weren't for one little detail: when a user 
searches for content, we would have to precompute a list of all the 
local roles the user has throughout the tree in order to populate the 
"qualifiedRoles" query.  That would eliminate the usefulness of the 
catalog query altogether!

So how can we deal with this?  Well, what if local roles were stored on 
the user object instead of in the object hierarchy?  To populate the 
qualifiedRoles query, we would ask the user object for the complete list 
of qualified roles the user has.

This would have a couple of nice bonuses.  Since all roles would be 
managed by the user folder, people would be able to manage all user 
roles in one place.  An administrator would be able to look at *one* 
screen to see what a user can access.

There's a new catch, though.  When you catalog an object you have to be 
able to compute a list that will match all possible qualified roles. 
What if someone has the "WorkgroupMember" local role in the 
"/workgroups" folder?  That should grant them access to object "A".

There are two answers to that question that I can see.  One is to create 
a special catalog index for the purpose of role-based filtering.  It 
would take into account the inheritance rules.  Another option is to 
populate the qualifiedRoles field with all permutations of object 
ancestor paths and roles.  Object "A" might be indexed with 9 
qualifiedRoles.  This isn't *too* bad since the number of qualifiedRoles 
probably won't reach triple digits.  (I can explain that better if you 
like, but the special catalog index is probably a better option.)

So, in summary...

I would like to move all local role storage and management to the user 
folders.  It would make it easier to administrate a system and would 
make CMF more scalable.

Shane