[Mailman-Developers] password handling in MM3

[David Brown]

[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 at aasv.org ; webmaster at aasv.org


-----Original Message-----
From: mailman-developers-bounces+dave=aasv.org at python.org
[mailto:mailman-developers-bounces+dave=aasv.org at 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 at 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