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

[Terri Oda]

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.

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

3.  While I agree that thinking about these things in advance is useful, 
I think this discussion is starting to crowd out discussions of 
time-sensitive things like students' GSoC applications and architectural 
choices that directly impact how they write said applications.

4. Let's be realistic: No one is going to plumb everything carefully 
through with good architectural work in time for it to be useful to GSoC 
students starting in a few weeks.

So... can we please backburner parts of this discussion until after GSoC 
so that we don't make it impossible for anyone to start on any project 
involving extra profile info? I don't want to bog down a student with 
the need to make this choice and work with these decisions at this stage.

For the purposes of GSoC this summer:

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.

We can re-open the floor to better ideas either after GSoC, after the 
Mailman suite releases, or if Barry vetoes my decision.  ;)

  Terri





On 13-04-28 10:24 PM, Richard Wackerbarth wrote:
> Steve,
>
> Here I agree with you.
>
> It is useful for MM to be able to accept enterprise information when it is available.
> OAuth is a mechanism that will be useful for some enterprises.
> To the general public, being able to use enterprise identification from common sources such as Google or Twitter, is a "friendly" way identify a user and allow them to log into a MM system.
>
> Within a MM installation, OAuth could be used in a more robust distributed implementation. However for our purposes, much simpler schemes such as Basic or Digest Auth is more than adequate for the intercommunication between components such as "core", "postorius", a message store, etc.
>
> Richard
>
> On Apr 28, 2013, at 11:07 PM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>
>> Xu Wang writes:
>>
>>> As oauth supported google's userinfo API, one need to present a valid
>>> google's oauth access token to get access.
>>> s/google/mailman/g  on above statement, it will be true too.
>> I disagree, in the sense that Google (as an OAuth provider) is in the
>> business of *providing* enterprise workflows such as AppEngine.
>> That's why they need to be an OAuth provider.  Mailman is a support
>> function for workflows (enterprise or otherwise).
>>
>> So it's not a "Mailman" token.  It's an <enterprise> token, and the
>> enterprise, not Mailman, should be the provider.  If Mailman provides,
>> then we have to take responsibility for foreseeing enterprise needs.
>>
>> If we go Wacky's route and make everything as generic as possible, we
>> may need the power of OAuth to handle all that genericity.  (We may
>> also then need another 5 years to release Mailman 3....)  But if we
>> stick to the current role-based authorization model with a small fixed
>> set of roles, then OpenID-like workflows (whether implemented via
>> OAuth protocol or otherwise) should be enough.
>>
>> If a site demands more control over authentication than public OpenID
>> providers can afford, then Basic Auth over HTTPS fits into the "user
>> has role" authorization model as well as OpenID does.  I don't see a
>> need for Mailman to provide an authentication provider, and there are
>> serious downsides to the proliferation of authentication providers.
>>
>> Steve
> _______________________________________________
> 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/terri%40zone12.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>