[Zope] permission and role questions
Rob Page
rob.page@digicool.com
Thu, 15 Apr 1999 11:01:31 -0400
Keith:
I can answer some of the more basic questions -- you ask some toughies
so I'm hopeful others can add some insight.
> 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.getUserName()-->
> 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?
We use this rhythm a LOT!
<UL>
<LI><A HREF="PublicRoom">Public Room</A></LI>
<!--#if AUTHENTICATED_USER.has_role('Room1Group')-->
<LI><A HREF="Room1">Room 1</A></LI>
<!--#/if-->
<!--#if AUTHENTICATED_USER.has_role('Room2Group')-->
<LI><A HREF="Room2">Room 2</A></LI>
<!--#/if-->
</UL>
Of course, the Room1 and Room2 folders should have the appropriate
permission set -- this only controls the UI.
> 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?).
Zope is architected specifically to allow a modular authentication
scheme -- you should check out UserDB at:
http://www.zope.org/Download/Prereleases/UserDB
While officially unsupported, it allows you to go to a relational
database for authentication. Of course, the underlying SQLMethods are
exposed so you could "go to town" on customizing your auth policies.
In the database you could actually store a attribute of each user with
is their external system id (e.g., external_sys1_id and
external_sys1_password), retrieve this w/a SQLMethod and send it off to
the other external system for authentication.
> 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?
bubububub.... Don't have an answer for this one -- this needs a higher
Zen level - maybe someone else can answer this?
> 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...
Hmmm.. I don't think this will work. Why do you want to avoid defining
the roles at the top of the Zope hierarchy? IOW, if you define the
folders at the top you could still restrict access to subordnate folders
per those role definitions.
> 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?
How would you define a subsystem?
> 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...)
Yep!
--Rob