[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, kerberos, etc.) were protocols whereby one system (the provider) furnishes credentials for a second system (the client) to some third system (the consumer).

By configuration, the consumer trusts that the provider has verified the client's identity and furnished appropriate credentials.
Thus, when the client presents credentials in an interaction with the consumer, the consumer provides services on the basis of the credentials.

If we assume that we distribute the MM implementation to include more than the two (core and web UI) systems by having, for example, a user manager, there might be an argument for passing around such credentials.

However, the design that has been followed thus far does not have the client communicating directly with the consumer system. Instead, the web UI interacts as an agent for the client. In this model, we have implicitly trusted the agent to properly represent the client and also screen client requests in accordance with system policy. Thus, although we need some level of authentication of the agent, there is no need for third party credentials such as those implemented in oAuth.

A connection on "localhost" is a form of credential. Trusting that the OS design restricts access to the connection, and trusting the applications running on that host provides a level of identification and trust.

There is no reason why alternate channels cannot be substituted as long as a means of identification (such as shared secrets) is utilized.
In those cases, the security of the communication channel and the trustworthiness of the agent system need to be considered. However, in a logical sense, the interaction is the same as one using the localhost channel.


On Apr 18, 2013, at 4:27 AM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> 2013/4/18 Stephen J. Turnbull <stephen at xemacs.org>:
>> Florian Fuchs writes:
>> 
>>> 5) It should implement an oAuth provider.
>> 
>> I don't see this.  Mailman is an auth consumer.  The only people
>> Mailman can provide auth for are the site admins.  Everybody else is
>> more or less untrustworthy.
>> 
>> I can see that there are applications where it would be useful to have
>> an auth provider bundled with Mailman, but I think implementing it is
>> somebody else's job.
>> 
>>> This could be used for API authentication and to log into
>>> Postorius/Hyperkitty
>> 
>> I think generic auth provider is overkill for these purposes, and a
>> trap for anybody who thinks we know enough about crypto/security to do
>> this stuff well.
> 
> I agree it's probably not easy. And, yes, maybe we need someone to
> help us with that.
> 
> But maybe we can take a moment to think about the usefulness of such a
> feature and the possibilities this might open up, rather than
> dismissing the use of a certain technology right off the bat. If we're
> unsure we can implement this in a secure way, we can still say no to
> this. Also, who says such a feature would be enabled by default? We
> can add it as an "experts only" thing and leave it up to the admins to
> make sure they use it in a secure environment.
> 
> I remember several discussions during PyCon(s) and on IRC where
> scenarios of different mailman instances talking to each other came
> up. Of course that doesn't mean implementing  a generic oAuth provider
> is the only answer to this. If there are better and easier solutions,
> fine.
> 
> Luckily going beyond localhost isn't something we need for the
> prototype that Terri suggested to be built for GSoC.
> 
> Florian
> _______________________________________________
> 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/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9