[Zope-dev] Help on Zope security needed ...

[Joachim Werner]

Hi!

I'm feeling that my head could explode sooner or later. But I'll try anyway
to sort out that security thing:

So what we are building is a content management system (Kontentor) that,
unlike the CMF, can have as many "sub-portals" to a portal as you like. We
are initially doing this for a university. So there this the main site of
the university, with some target-group-specific portals like "studying
abroad" or "alumni", and then there are the sites of the faculties (or
"schools") (e.g. "School of Business") and institutes, which themselves
contain sites for departments (e.g. "Department of International
Marketing").

The look&feel ("chrome"/"skins") and basic site layout should be enforced
globally.

There is a role model with "Editors" and "Reviewers" (a bit simplified, but
it will do for the example). People can hold these roles for branches in the
tree, e.g. somebody could be Reviewer and Editor for the Marketing
Department, but only Editor for the Business School site. In addition,
he/she could also be an Editor in a completely unrelated branch, let's say
in the Computer Science Department.

So these are the security-relevant use case that I have to deal with:

1. An Editor for anything on any branch in the tree should be able to SEE
the managementButtonBar on top of the site when logged in
2. An ordinary visitor of the site should NOT SEE the managementButtonBar,
not even if he/she calls the object's URL directly
3. On the sites the Editors are responsible for, they should see and be able
to use in-site management buttons/icons like "move up" or "delete" for all
elements they are authorized to edit (i.e. NOT the basic elements that are
pre-configured by their "parent" site, like site-wide menu bars etc.).

In terms of actual coding, I do not want to have to check for security, just
do things like "<dtml-var managementButtonBar missing>" or try/excepts in
Python. If I have to hard-wire things like "if user is Editor then display",
I won't be able to change the names of the roles etc. later.

Let's say we have a security model that checks like this: "If the current
user has a role that is linked to my permission, and he has that role for
the container I am in or for one of its parent containers, then grant
access!". That's how we all thought the Zope security model should work. So
if I am an Editor in the Marketing Department, I can edit all local elements
whose "manage_edit" method is bound to a permission "Edit Content Object",
which is globally bound to the "Editor" role. Even though I have the Editor
role, I can NOT edit objects of the same type in other branches of the tree
(e.g. the Computer Science Dep.) or up in the tree (i.e. on the root level
of the Business School). Fine. So if everything that seems to be broken in
the security model is fixed, number 3. is partly doable.

But let's go to the rest of the use cases, and a missing aspect in case 3.:

How would I normally do No. 1? I'd bind the "view" permission of the
managementButtonBar to the Editor role. That way I can say "<dtml-var
managementButtonBar missing>" in the index_html, and voila: an ordinary user
would not see the buttons, but my Editor would. Yes, but only if he is an
Editor in ROOT (that's where the managementButtonBar DTML Method is at
home).

If I choose to NOT protect the managementButtonBar directly but to do things
like "<dtml-if AUTHENTICATED_USER.has_role('Editor')>", the DTML Method will
be callable by anybody directly. This may not be an issue for the management
button bar, but it would for more security-relevant methods.

The crucial point is: Everything works fine if I can bind my roles to local
instances of the Product, e.g. a local "faculty" instance. Then, the Editor
is editor for THAT instance. But as soon as I want to use acquisition for
some of the display methods, those will not work as needed.

So what we seem to need for those is the possibility to say "any Editor on
any level in the hierarchy should be able to use this", or as an
alternative, "faculties (or whatever other sub-object we have) can acquire
this method as their own and make it available to their Editors, but if the
object is called directly, it is protected".

Probably the only way of doing most of this with the current security model
is having myriads of Roles, like "Editor of Business School" or "Reviewer of
Computer Science Department", and putting all the users into the ROOT
folder. That's rather ugly ...

O.k. Have I lost all my readers now? If not, I'd like to hear what you think
... ;-)

Joachim