On 21-Jul-17 22:58, Barry Warsaw wrote:
One big project that I’d love to see gain more traction is Lemme, our authenticating REST proxy. We just haven’t had much collective resources to spend working on it.
https://gitlab.com/mailman/lemme
Cheers, -Barry
It's not obvious why this is a 'big project', or why it needs to be a separate proxy. Modularity can go too far.
The architectural problem with a separate proxy that provides separation of privilege is that the proxy has to be kept in sync with the core - add an object or property to the core, and the proxy has to be updated. You'll end up mirroring the decoding and structure of the core in the proxy in order to figure out what the access rights are. Or the proxy does just authentication and passes on a token used for authorization - in which case the proxy isn't adding much value. You already have a database of users & passwords - adding another database for the proxy is not going to simplify the admin's life.
In addition, as the recent issues indicate, the REST API already has scaling problems - adding a proxy in the path will exacerbate those.
The REST API supports Basic authentication - which is adequate for identifying users and delivering passwords, if over an encrypted link (e.g. TLS, which is easy to set up with standard libraries). Personally, I prefer client certificates as an identifier - which again, your TLS library will validate. They can be mapped to a username easily
- just add the certificate's issuer and subject to the user data. TLS will handle verification & revocation (CRL and/or OCSP with your "trusted authorities" bundle or path). Webservers handle this, and can be used as a model. (E.g. apache's mod_ssl).
What's missing is a STARTTLS-like mechanism in the REST API, a privileges field in the user and/or list databases, and suitable checks in the API actions. Even that can be simplified by requiring TLS for all connections, even local ones. I prefer that approach, as it reduces bugs and corner cases. For backward compatibility, a global configuration setting for TLS on or off can be added.
Alternatively, you can use a webserver as a reverse proxy & let it handle the authentication. You already do this with DJango. The drawback is that the path from the proxy to the mailman REST server needs to be protected or trusted - a local socket on the same machine as the webserver is one approach. But that limits configurations. Or you can use TLS from the webserver to the API - but setting that up (and documenting it for users) is more work - and at that point, you've done 95% of the work for a direct TLS connection. (The advantage is where the webserver provides single signon authentication.) So I'd avoid this path & implement TLS in the REST server.
Either way, the major work is (or should be) authorization tests in the core, with a touch of mapping an authenticated user to her(his) capabilities (for a list) in the database. Not a s"big" separate project.
Why have you come to a different conclusion?