OK.
How about I make a standalone User Authorisation based server that has a user data store with additional arbitrary user keys in it? It would also allow role information to be assigned to those users via it’s own REST API (which I would have to think about and make up).
Thus my API proxy (I’m calling it CrowdWave) will be a public front end that looks like this:
public HTTP request <==> CrowdWave API proxy <==> Mailman REST API public HTTP request <==> CrowdWave API proxy <==> CrowdWave User Authorisation server
The CrowdWave User Authorisation server will use Falcon and Sqlalchemy with a default sqlite database.
I’ll just do it to meet my need for resolution of question of how to give public access to higher than list level functions. I’m not going to overthink it because I just want a way to give public access to all Mailman REST API functions. Consistent with earlier discussion, the CrowdWave User Authorisation server would not in the short term be part of the Mailman project and would be a third party project.
After this is built it might be an effective thinking point for working out the official mechanism for authorisation.
Barry - if you want me to implement a specific approach now would be a good time to say - I’m happy to do anything as long as I feel up to it from a coding perspective. Right now I’m aiming for super simple.
What do you think?
as
On 26 Jan 2015, at 4:44 am, Barry Warsaw <barry@list.org> wrote:
On Jan 24, 2015, at 04:05 PM, Andrew Stuart wrote:
The main thing I’m looking for is whether there is an authorisation concept that operates at a higher level than the list.
No, there isn't[*].
I wonder is there the concept of some sort of “special” mailing list that is different or hidden or privileged in some way? There is a reference in the documentation to a “site list” but I coudn’t find much more about it. If there is a “special” list then maybe site wide user priveleges can be stored against it.
There is no site list in Mailman 3.
I can see there is a site_owner in the Mailman config file although this just seems to be an email address to get bounces in certain circumstances, is it used for anything?
Just for bounces, as you've discovered.
Well I read the discussion thread. I had no idea so much previous thinking had gone into this. Funny that there was so much discussion but no-one has really chimed in with an opinion about how I’ve built the authentication proxy - maybe everyone’s gun-shy. :-)
I haven't yet had time to dig into your work - apologies for that!
The only unresolved question for me coming out of all that is “where is it specified which users have access rights to carry out functions at a higher level than the list?”
It appears that such information is not part of the Mailman core user data model and needs to be handled outside Mailman core i.e. at the application level.
This is correct. It's the big reason why currently the API is an all-access administrative API. If the core was explicit in the roles an access right, then an authenticating proxy wouldn't be necessary.
Sumana's summary is essentially correct. There seems to be 6 (-ish) natural roles that actors can play. We can disregard the site administrator as that's the person with shell access and the necessary permissions to "pop the hood" and do anything.
Given that we have mailing lists organized into domains, it makes sense that each mailing list have its owner, each domain have its manager, and the system as a whole has a manager as well. The system manager can do things like create new domains, install global bans, and can delegate responsibility for domains and mailing lists to others.
For a site with multiple domains, a domain manager can create lists within that domain and delegate management of mailing lists to the owners of those lists. List owners can change any setting, and can delegate moderation privileges to list moderators.
Users can manage their own subscriptions, and the various settings associated with their memberships.
In Mailman 3, this breakdown is purely conceptual, and as you've seen there has been heated discussion in the past. I'm open to rebooting that. I have strong opinions but am willing to be persuaded, especially if there is code to back it up. :)
Personally I’d store such user information inside the Mailman core data model. Things start to look weird when application X has a different mechanism for deciding who can do admin tasks to application Y. Maintaining such info outside the core also calls for user database synchronisation which would be good to avoid. But I don’t really mind I’m just trying to get a secure way of deciding which users to allow to do higher-than-list-level functions.
Alternatively, once the core bakes in these assumptions, then it becomes very difficult for other tools to experiment with other ways of doing it, or integrating the decision making with other external systems.
I've been of the mind that we should define a service that defines this breakdown as interfaces and APIs. Then we would be free to implement this as a third party tool that peer with the core, Postorious, HK, the API proxy, and others. We could provide a reference implementation for those who want a simple turnkey solution, but integrators would also be free to back those APIs up with alternative implementations based on their specific needs.
As it turns out, the core doesn't have a lot of need for this, which is another reason I've so far resisted tightly integrating it with the core. Maybe we'll find some interesting uses once such a service is available though.
1: eliminate public access to all functions that operate higher than list level
2: bake my own additional level of user authentication that defines which users have higher level access rights.
3: find a cheat/workaround to store arbitrary keys against users (this my preferred solution)
4: something else
Option 1 drastically reduces the usefulness of the interface if only list level functions can be executed. Not ideal.
Agreed.
Option 2 I would prefer to avoid - my authentication proxy doesn’t actually know much about Mailman at an application level - all it does is authorise and authenticate and pass through requests to Mailman if the user is allowed to do it, and reject them if not.
Option 3: find some sort of cheat/workaround - preferablyt a way to store additional user information in a user profile field which allows storage of arbitrary keys. Then I could stash some access control information in there that tells me that user X or user Y has some higher level access control. This would have to be do-able via the Mailman REST interface cause it’s the only way that I talk to the system. The ability to store arbitrary key/value information against a user would be the ideal outcome at this stage.
This is very close to the system I've envisioned, although I would make it a separate system with a separate API. The proxy would then talk to this API when it needed such information.
Cheers, -Barry
[*] There's still the moderator_password turd in the mailinglist model. I think I need to get rid of that now once and for all. :)
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9