[Zope] permission and role questions

[Michel Pelletier]

> -----Original Message-----
> From: Keith Rohrer [mailto:KRohrer@hnv.com]
> Sent: Wednesday, April 14, 1999 8:05 PM
> To: 'Zope Users List'
> Subject: [Zope] permission and role questions
> 
> 
> I'm working on designing a web application, and right now I'm 
> particularly
> scrutinizing Zope's permission model.  In trying to think how 
> I'd use it to
> do what our existing, highly custom system does today, I wonder:
> 
> 1) How does one examine the logged-in user's username from 
> DTML?  I think I
> just need the variable name here...

<!--#var AUTHENTICATED_USER-->

AUTHENTICATED_USER is a user object returned by the acl_users object.
In the case of a regular Zope User Folder, an etcUserFolder, or a UserDb
folder, the AUTHENTICATED_USER object is a AccessControl.User.BasicUser
instance.  In the case of an IMAPAdapter object, it is an IMAPUser
instance.  The above var tag will render the user name of
AUTHENTICATED_USER.

> 
> 2) Once I know the user ID, how can I get a list of places the user is
> permitted, so that all users can enter via one "front door" 
> that always
> shows exactly those rooms the user may enter?
> 

User have Roles.  Roles are abastractions like Manager, SalesGuy,
IMAPUser, or whatever else you want to call a Role.  Object and methods
in Zope have certain permissions.  You can turn on or off certain
permissions for certain Roles on individual objects and methods in Zope.


Exactly how this access control model works is detailed in the Zope
Managers Guide starting around page 17.

> 3) Is there any form of permission inheritance or 
> impersonation implemented?
> Our application interfaces with other systems, and maps some 
> local user IDs
> to remote user IDs.  Assistants log in with their own IDs, then pick a
> "primary" user on whose behalf to work; the system then uses 
> the "primary"
> user's permissions and presents the "primary" user's remote 
> credentials.
> I'm thinking I'll have to do this myself, since I need to 
> keep both IDs
> around for auditing info...fortunately I'm already expecting 
> to use a custom
> authentication layer (ever try to time out a session with basic
> authentication?).

Objects can acquire permissions from the objects that contain them.  If
you set a certain flavor of access control on a folder, you can specify
that you want the contents of that folder to acquire their parent's
permission settings.  'Acquire Permisssions' is the default on all
permissions.

> 
> 4) The security screen's permission settings have "acquire" 
> checkboxes,
> whose point is obvious, and per-role checkboxes.  I take it 
> those enable
> permissions?  So we can allow inherited permissions, and we 
> can explicitly
> add permissions, but there's no way to add-only-if-inherited or
> inherit-but-deny-particular-loons-anyway?  Also, the permissions on
> intervening levels of the tree are not checked, only inherited, right?

'Acquisition' isn't a name we use to mean 'Inheritance', Acquisition is
actualy a complimentary mechanism to inheritance.  There are several
good documents on it here (http://www.zope.org/Documentation/Reference),
and this morning I released some rough draft documentation that included
some acquisition stuf on the the zdp list
(http://www.zope.org/mailman/listinfo/zdp).  By checking the acquire box
in the security tab, you are telling that object to accept the same
permission settings as the parent that contains it.  The parent may also
be acquiring from *its* parent, and so on, till it reaches the root
folder.  At each step in the object heirarchy, you are given the ability
to make security restrictions less general and more specific to your
application.

> 
> 5) If I define users at a high level, can I grant those users 
> roles defined
> at deeper levels?  This would make my job with point (2) much 
> easier, as I
> could create roles Foobar_Peon and Foobar_Boss in the Foobar 
> folder, then
> offer the user buttons into Foobar if they have 
> Foobar_whatever roles...

Users 'at higher levels' cannot be given Roles defined below them, but
this behavior is easy to emulate with the system, just give them a
higher level role that is the superset (contains all of) the permissions
that the role you want them to be lower has.  Users have Roles, and
Roles are collections of permissions.  You can have a Role which allows
many permissions defined higher up, and the more specialized you get
(farther down) you can create more restricted roles that are subset
(contain a portion of) the higher level role.

> 
> 6) Is there any plan for, or how hard would it be to 
> implement, a "reverse"
> permission manipulation screen where the role is fixed and 
> the subsystems
> are columns?
> 

I'm not sure why you would want to do this.  I'm guessing it's possible
and cleaner to do whatever you have in mind with the current method.

-Michel 

> 
> I'm largely looking at Zope and ACE--and may wind up using them in
> conjunction somehow--to recommend as frameworks; ACE (plus 
> TAO) has good RPC
> and OS abstraction layers for C++, while Zope is a much 
> richer framework for
> web applications.  If I have to write in permission checking 
> and proxy users
> along with the audit trail and the actual application 
> functionality, no
> biggie...
> 
> 	Keith (I may need to inhale the developer docs now...)
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
>