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