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

[Ken Manheimer]

On Mon, 10 Dec 2001, Guido van Rossum wrote:

> Ah, that *does* clarify things.  So role names and role-to-permission
> mappings are totally global and central?

Not quite.-)

Each object can inject its own role-to-permission mappings, including the
choice to acquire each mapping from its context (container).  You've
probably seen the "security tab" ZMI screen - it's a matrix for making
those assignments (including the "acquire from context" choice).

I think that, ideally, it's relatively rare to create new roles, while
role-to-permission mappings are typically adjusted on a per-product basis,
and role-to-account mappings are adjusted (using local roles) on a
per-instance basis to assign privileges to particular users within the
context of the instance.

Here's how i see it, in practice.

There's a benefit in having common role names across a site, so that
someone can be assigned a role high up to get privileges accorded that
role within many different contexts.  A prime example is the "manager"
role.

Within the context of a folder, manager may be able to delete and add
stuff regardless of the folder's ownership, while within the context of a
collector, a manager may be able to adjust supporter settings and access
private issues collector-specific duties.  This way, someone with manager
role in the root of the site gets manager-oriented privileges in all
contexts that follow this convention.  Further, the collector reuses the
"reviewer" role for supporter duites.  "Reviewer" has the authority to
approve publication in the context of documents, in the collector they
have authority to handle issues...

Role-to-permission mappings associate the privileges with the roles, and
are generally twiddled programatically by the product across its
instances.  Role-to-account mappings - using local roles - are adjusted by
the product as role-assignments shift within the instance.

(It may make sense for the security system to solidify the institution of
common roles, and the ways that new roles are created, to support the
reuse of roles across products.  I'm not sure exactly how this would be
realized but the pattern is not immediately obvious, and i think it's key
in the coherent operation and management of a site...)

> > Anyway, i guess i figured that the meaning of "obtain" in the more common
> > construct is sufficient cue.  I think my mind grasps language according to
> > such cues (perhaps we have different internal strategies...)
>
> I was actually thinking that there was a word missing from the
> sentence - or that it was an example of Ken-speak. :)

The dangers of my ineptness in following conventional interpretations - i
don't mean to say things differently...

> I'm now assuming that "X obtains" is the same as "X can be obtained",
> the way you use it here.

Hmm.  The canonical use could be "rule X obtains in situation Y".  I don't
think it would work to say "rule X can be obtained in situation Y".
Rather, "rule X holds..." or "rule X applies...".  (For me, "obtains" is
significantly less ambiguous than the other choices, so i find it
appealing...)

-- 
Ken
klm@zope.com