[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:54 PM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> 2013/4/18 Richard Wackerbarth <rkw at dataplex.net>:
>> 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.
> 
> I was primarily thinking about the (future) authenticated REST API in
> Postorius. In that scenario a third party web app that we don't know
> would request an access token from the user profile store (provider)
> as well a user's email address. It would then use that access token
> for requests to the Postorius API (consumer).
> 
> If the instance of the user store does not act as provider, we would either:
> 
> 1) effectively require every api user to have an account with some
> other oauth provider.
> 
> or
> 
> 2) use some other authentication method.
> 
> 
> 1) is odd in my opinion. Mailman is free software. And there are not
> too many oauth providers that match that philosophy.
> 2) would be totally great if we found something that doesn't require a
> user to provide his credentials to said 3rd party app.

Look at what happens now.  The user contacts Postorius and presents either some oAuth/BrowserID-style credential or it presents a username/password. In exchange, Postorius issues a local credential (session key).

When the username/password path is chosen, Postorius acts as an agent for the user and verifies the login. In this case, Postorius must "see" the underlying credential (username/password pair) to be able to present it to the authenticator.  In the oAuth path, Postorius never sees the underlying credential, but exchanges the presented one for its local credential.

Since we consider the user manager to be a part of the MM complex, what have we gained by hiding the underlying credential from the web interface?

Therefore, I would suggest that we need to be able to accept third-party (oAuth) credentials and also locally presented ones.
I don't see where we gain an advantage by exposing the authenticator as a separate oAuth provider.


> I don't know. Maybe I'm missing something. And of course I agree with
> Stephen: If it's too hairy in terms of security, we should not do it.
> 
> Anyway, we're talking about something that is absolutely not needed
> for what we want to achieve *right now*, which is a profile data store
> that Postorius/HK/etc can access from localhost (or maybe from an
> internal network. Or IP-restricted through SSL. Or... ?).
> 
> Florian