[Zope] RE: [Zope-dev] pam authentication support with PyPam

Alexander Staubo alex@mop.no
Mon, 18 Oct 1999 18:43:49 +0200


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