[Sorry I'm late... didn't notice this list is set to reply to sender instead of the whole list.]

In model/docs/users.txt, it says "Users are entities that represent people. A user has a real name and a password.... " As yet (rev 6869), none of the methods provided in the class User itself make use of that password.

LDAP and OpenID are fairly common situations where using Mailman's own username/password is not helpful. I know that one of my major challenges with MM2 was whacking it upside the head hard enough that I could use the AASV's membership database instead of Mailman's users to control access (it sort of half works) and list membership (still using the import script :-( ).

An extensible plug-in architecture would be really useful here, I think. You could even have a plug-in that determines what plug-in to hand-off to -- for environments like Ian's where some users use LDAP and some use a stored/hashed password.

Presuming the storage mechanism isn't limiting the length of the "password" (i.e., only 32 characters for a hex MD5 or something like that), I think that this field could be overloaded to support a variety of uses and plug-ins. If we used something akin to IRI/URI/URL formatting, the authentication method used for a particular user account could be represented right there. For example, plug-ins that come bundled with Mailman could use the plug-in name in the method part:

openid:///myopenidusername.openidprovider.com ldap://ldapserver.example.com/username sha1:///6aafb9bd47e1a38bbb99043c638f192f89c87930

Plug-ins created apart from Mailman could be loaded via a "private" plug-in that loads the user identified by the host.domain part of the URI to protect against name collisions:

private://members.aasv.org/whatever_private_data_I_want_goes_here

(You could still fall back to the password field containing just a hash and hope/presume it's an unsalted MD5 or something like that.)

For web-based authentication, there will need to be some sort of authentication target page that can load the appropriate plug-in. In the example of OpenID, the user might typically be redirected away from the mailman host to the OpenID provider's page, then come back to mailman via GET with validation information in the query.

Another issue to consider is that the "real name" attribute of the Mailman User might better be obtained from the external authentication service/plug-in -- such as LDAP or OpenID, (or the AASV member database). Indeed, it seems that the essential role of the Mailman User is to provide a root node for the collection of associated addresses and their memberships. Having the password and real name attributes makes it a lot easier (possible) to install and configure Mailman as a standalone application, but they are somewhat superfluous when they can be obtained from a more authoritative source.

Dave

David Brown dave@aasv.org ; webmaster@aasv.org

-----Original Message----- From: mailman-developers-bounces+dave=aasv.org@python.org [mailto:mailman-developers-bounces+dave=aasv.org@python.org] On Behalf Of Anna Granudd Sent: Friday, July 09, 2010 6:12 AM To: Mailman-developers Subject: [Mailman-Developers] password handling in MM3

Hi, when subscribing a user or creating a list in Mailman 3.0 we need to implement the use of a password for security reasons. Later the same password will be used for logging in to the settings pages. At the moment passwords are not handled at all which is why I filed bug #600780 (see [1]). However, we're not sure how to handle the passwords at the moment and would like your help with ideas and possible ways to implement this, which is why I want to start a discussion about the password handling/ login function. What do we need to think of and how should this best be dealt with?

Thanks, Anna

[1] https://bugs.launchpad.net/mailman/+bug/600780

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/dave%40aasv.org

Security Policy: http://wiki.list.org/x/QIA9