[Mailman-Developers] Some raw thinking on user level authorization and authentication

[Barry Warsaw]

Hi Andrew, thanks for starting to look at this.

On Dec 17, 2014, at 09:29 AM, Andrew Stuart wrote:

>step 1: authentication
>—- HTTP client provides username and password
>—- username and password sent to Mailman REST server
>—- if Mailman REST server authenticates username and password:
>—- authentication token returned to client

MM3's REST API has the resource <api>/users/<uid>/login which you can POST to
with form data `cleartext_password` as the authentication step.  You get back
a 204 if the password matches, and a 403 if it does not.

>step 2: authorization
>-- examines inbound requests
>—- if request contains valid authentication information, continue
>—- examine requested Mailman resource
>-— send REST request to Mailman REST server to find out if this user is
>-allowed to do this resource request

This is the trickiest part because we don't currently codify what a particular
user is or is  not allowed to do.  We'll need to do this carefully, and the
question is whether that information should be kept in the core or in the
proxy layer.  I wonder if there is prior art or best practices on how best to
specify authorizations to REST resources and methods.

>—- requires execution of the Mailman REST API as a wsgi application, which is
>potentially complex and more tightly coupled than desirable and would require
>implementation into the Mailman code base

It already is a wsgi application actually.  But I think the bigger problem is
that we want admins to be comfortable exposing the full admin API only on
localhost, and they'll need to expose the proxy on a public IP, so it's likely
that the proxy would run on a separate machine/VM from core.

Cheers,
-Barry