[Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

On Apr 29, 2013, at 3:06 PM, Terri Oda <terri at zone12.com> wrote:

> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be supporting Mozilla Persona and passwords as authentication methods.  This is not up for discussion at this time; it's a choice we've made to in order to help move the release forwards.

That doesn't bother me as long as we recognize that the list of acceptable methods be extensible.
In other words, adding a new method would require only the addition of the necessary handlers, forms, etc. and NOT require the re-engineering of the code that handles BrowserID or username/password.

> 2. As such, any discussion of enterprise use of google or twitter or what have you is pretty much academic.   I am satisfied if our authentication plan for methods other than Persona and passwords is "And then the magical python gnomes associate an external account with an internal mailman account!"  (I'm not being entirely facetious here; libraries such as django-social-auth are likely to make this sufficiently trivial that it might as well be gnomes.)

Agreed.

> Authentication for the purposes of the extra profile info data store will be provided by either Persona through the web interface or passwords.  Yes, even internally for the REST interface: passwords+localhost are good enough for Mailman Core right now, so it's good enough for anything else we do short-term.

I'll go further than that and suggest, for the purpose of GSoC:

1) The USER module will be implemented as a Django 1.5 app.
2) In addition to a custom user model (https://docs.djangoproject.com/en/dev/topics/auth/customizing/#auth-custom-user), it will provide a Credential verification service.
	The service will store the associations between users and the parameters used to identify them -- protocol, identifier, confirmation. If the credentials match, the service will return a user_identifier which will be used to access additional information about the user. 
3) The user_identifier will be of a form chosen by the USER module. Other modules (such as MM-core) may associate alternate identifiers (in their namespace) and set or retrieve them. When installed as a part of a MM system, at the installer's discretion, additional user profile information may also be added.

4) Both the User information and the Credential service will be exposed on a RESTful interface.
5) This Django app may be installed as a part of a Postorius interface or run as a standalone service.

In the future alternate implementations might be considered, but this will do for now.

It also has the advantage that multiple students can work on things affecting the user record without the other student's work becoming a stopping point to their progress.  Then, as they get them working, they can be merged into the postorius system.