[Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

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.

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