Hi benste,
On May 27, 2011, at 05:46 PM, Benedict Stein wrote:
wacky and i discussed a few things about how to implement ACL within the Mailman3 parts. I've wrote a small Blogpost about it in http://benste.blogspot.com/2011/05/mailman-3-restapi-webui-acl.html
just in case you want to contribute to Pro/Con list directly go to http://wiki.list.org/display/DEV/Pro+-+Con+ACL+in+different+Layers+%28WebUI%...
There's another way of implementing ACLs, which would be useful to explore, and which is what I've had in the back of my mind for a while now.
First a quick review. As you mention, I've long advocated that the core's REST API be a full-permission, admin-only API. The requirement here of course is that it can really only be published over completely trusted channels, and we've said for several years now that this means only on localhost. As you point out this has several advantages:
- It keeps the REST API simple
- It keeps the data model simple
- Clients have unlimited functional flexibility
- Not locked into the core's perception of permissions and security
As you rightly point out, the downside is that the core is essentially punting, and requiring all of its clients to implement security, access, and permissions.
In my mind, I've always thought that you could implement some middleware to handle this, in a way that would better serve clients. For example, if I had some middleware that also exposed a REST API, but required authentication for each request, it could do the permission check, filter the request as appropriate, and forward it to the core. Of course, responses could also be filtered if necessary, but this would present exactly the API that clients required.
This is appealing because it allows for pluggability and customization for various environments, without imposing extra complexity on the core. Here's another use case to illustrate.
Let's say I wanted to replace Launchpad's mailing lists with Mailman 3. Now, Launchpad has a very rich user and permission model, involving accounts, people, teams, OAuth, SSO, SSL, etc. I think it would be quite difficult to integrate Launchpad's notion of permissions into the core's model, or even to design the core's model so that you could plug things in at every level. It's much more approachable to me to just hook up the user and team model to be able to do the much easier task of determining list membership for posting purposes. Launchpad's own security infrastructure would limit who can do what to the Mailman core, of course through its own web ui and API. Launchpad itself would essentially be the middleware filtering requests to the core through its permission model.
Launchpad's security model would be very different from Mailman's Django web ui's model. It seems insurmountable to me that the core is the piece that resolves, integrates, and allows these divergent models.
I know it's a cop-out to keep punting on security in the core, but I actually think it's a *useful* cop-out. For the great number of sites I see as integrating Mailman 3 with their own web ui, they already probably have pretty complex systems with their own permission models, and I'm leery of adding the necessary complexity to the core for Mailman to be a client of those security models. For the great number of sites that will just use Mailman's Django web ui out of the box, we can use Django's features to implement security, with perhaps some well-placed queries into the core's API or database to determine membership relationships.
The core's job is to deliver email. It's existing "permission model" is just enough to decide whether and when to do that.
As always, I'm interesting in hearing other people's opinions on this, and will of course keep an open mind. I'm also not against adding some minimum of required functionality to enable this security middleware I'm thinking about. But I also think it makes a lot of sense to keep the core as simple as possible (but no simpler :).
Thanks for kicking off this discussion!
Cheers, -Barry