-----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 )