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
On Mon, 18 Oct 1999, Michel Pelletier wrote:
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.
I started hacking the etcUserFolder into GenericUserFolder. The idea was you provide DTML code for the following functions: - Retrieve list of users - Authenticate a user - Retrieve list of domains valid for user With these hooks, one userfolder can be distributed that allows admins to do anything that can be done in python. It also allows much more flexability (when I go live, I need to determine default roles and populate user lists from Oracle, and authenticate via Radius, LDAP, NIS+ or NT)
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.
acl_users (GenericUserFolder) - hooks - list_users - user_authenticate - user_domains - user_email - user_mycustomuserproperty - user_somethingelseonlymysitewouldeveruse - user_aquire - fred - MainDB (ZOracle DA) - jorge - MainDB (ZOracle DA) - role_aquire - academics - MainDB - officestaff - MainDB - contentadmins With a structure like this, we should be able to call: AUTHENTICATED_USER.hooks.user_mycustomuserproperty() Code can either call the hook and fail if it isn't found, or handle the situation gracefully as the developer chooses. user_aquire and role_aquire are to do with a feature I've already submitted to the Collector, and can be left till later. The idea is that if aquisition failed for some item, we traverse up the tree until we find a acl_users folder. We then try to aquire the object from (assuming user fred is an academic and content admin): acl_users.user_aquire.fred, acl_users.role_aquire.academics, acl_users.role_aquire.officestaff ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (2)
-
Michel Pelletier -
Stuart 'Zen' Bishop