There are two aspedcts of the current security subsystem that bug me. The first is the fact that only user folders are accumulative only at folder boundaries. You cannot create one UserFolder and one NTUserFolder at the same level and have them co-opt the user authentication responsibility. The second, more serious gripe is with the security permission model. Look at NT 4.0 and the security UI that comes with SP4/SP5's Security Configuration Manager for a good example (installing it will upgrade NT's security dialogs with a new UI). While Zope permits acquired, accumulative access definitions specified across _all_ roles for each permission, this is too coarse and leads to huge sysadmin headaches (I know -- I've been there, and I'm still there). We need fine-grained, per-role permissions that let us specify whether a role acquired the permissions of the parent, or whether it allows or denies the permission. Instead of the matrix we have today (below, "[X]" denotes a checkbox): Acquire Permission Anonymous Manager Owner [X] Access contents information [X] [X] [X] [X] View [X] [X] [X] [X] View management screens [X] [X] [X] ...we ought to have something like this (here, "[...][]" denotes a combo box): Permission Anonymous Manager Owner Access contents information [Acquire][] [Deny ][] [Allow ][] View [ ][] [ ][] [ ][] View management screens [ ][] [ ][] [ ][] Each combo box would be set to either "Acquire", "Allow", or "Deny". "Acquire" has the role acquire the permission setting of the acquisition parent. "Allow" specifically gives the permission to that role. "Deny", of course, explicitly denies the permission to the role. I shouldn't need to point this out as it should be paintfully obvious to anyone who has used Zope's permission settings, but the problem is that a role's permission setting is either allow/deny, but the acquisition switch applies to all the roles. One you un-check the "Acquire permissions..." checkbox, you must explicitly define the permissions for each role, independent of whether the role is relevant. In a small, flat, and/or simple ZODB this system is usually endurable, but in a real-world object hierarchy where roles must be delegated carefully, it doesn't work. The problem is exacerbated by the fact that Zope has no provision for summarizing the security permissions in effect throughout the site, or batch-applying security settings. If subfolder Foo's permission settings deviate from that of a parent, I can't know unless I go to the folder and look at the security tab. One folder is okay; if you have a hundred of those, it's a tad more serious. -- Alexander Staubo http://www.mop.no/~alex/ "Give me an underground laboratory, half a dozen atom smashers and a beautiful girl in a diaphanous veil waiting to be turned into a chimpanzee, and I care not who writes the nation's laws." --S. J. Perelman
-----Original Message----- From: Michel Pelletier [mailto:michel@digicool.com] Sent: 18. oktober 1999 16:13 To: 'Will Fife'; Oleg Broytmann Cc: zope-dev@zope.org Subject: RE: [Zope-dev] pam authentication support with PyPam
Regardless of whether or not Zope has a PAM folder (which I think is a good idea) we need to discuss an upcomming problem with Zope user authentication: the proliferation of user folders.
The problem is there are now quite a few user folders that all kinda look the same, smell the same, and share a good bit of code. This is very brittle. The 'backends' should be abstracted away from the 'frontend' and we should return to the original state of grace, one type of user folder.
At the moment if we were to change an aspect of Zope authentication that would break existing user folders, we would have to go and fix every single one, the orpaned ones without maintainers (like etcUserFolder, my personal orphan) would simply remain broken until someone got frustrated enough to fix them. This is a pretty bad state of affairs.
So lets fire up a discussion on what kind of model we could impliment to have a generic user folder with pluggable backends (one of which could be PAM). It might even be a good idea to look *at* PAM for some ideas, anyone here a PAM expert?
Hmm.. it might also be nice to take Membership and the ZPT into consideration here, like support for extensable user objects (if the 'backend' supports it) etc.
-Michel
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(Related lists - please, no cross posts or HTML encoding!
To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )