Hi Dick,
Is this about the MM3 web interface?
No I’m working on a REST API proxy which uses JSON web token for authentication - sounds like SAML is somewhat similar but JSON based. Postorius/Hyperkitty provides an end user web interface to MM3. I’m not sure what mechanism they use for user authentication - maybe Mozilla Persona, which I think uses JSON web token anyway.
as
On 18 Feb 2015, at 10:45 am, Dick Visser <visser@terena.org> wrote:
Hi Andrew
Is this about the MM3 web interface? If so, I wonder if it could work with SAML authentication. This can be done with PySAML2 (https://github.com/rohe/pysaml2), or in an Apache module (mod_mellon). The latter takes care of the authentication, and any web app protected by it can rely on (for instance) REMOTE_USER always being available.
Thanks
Dick
On Sun, Feb 15, 2015 at 9:05 AM, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:
I’ve just finished (mostly) implementing most of the authentication, authorization and permissions systems. Thought you might be interested in a little on how it works.
To discuss this further I need to explain a few things - apologies to those who i am teaching to suck eggs.
The auth server needs a few key subsystems to get the job done - authorization, authentication and permissions.
AUTHENTICATION - this is the process of the end user identifying themselves in the first place (in this case, by logging in with a username and password), then for every request beyond that, providing evidence that they are who they say they are - in this case, that’s done by giving them a token when they log in successfully, then requiring that the token be returned along with each subsequent request.
AUTHORIZATION - this is the process of determining if the authorized user is allowed - according to the rules of our application - to access the resource that they have requested. For example, user Jenny sends a request to access the members of a list named supermaillinglist@marketingcompany.com. Before we can execute that request we need to determine if she is *authorized* to do so.
PERMISSIONS - for the authorization process to do its job, it needs information about WHO is allowed WHAT LEVEL OF ACCESS to WHICH RESOURCE. This is the *permissions system*. It’s VERY easy to understand. Nothing more to it than a database table that looks like this user_id = Column(String, nullable=False) role = Column(String, nullable=False) resource_id = Column(String, nullable=False) resource_type = Column(Enum('list', 'domain', 'archive','server','domain', name='resource_type'), nullable=False)
The permissions system is a small extension of the existing Mailman permissions system. user_id = the Mailman user id role = one of ['domainowner', 'serverowner', 'userowner', 'listowner', 'listmember', 'listmoderator'] resource_type one of ['list', 'domain', 'archive','server',’domain'] resource_id = Mailman list_id or Mailman domain or ‘server’ or ‘user'
So with four pieces of information you can define access for any user to any Mailman resource. The permissions system is nothing more than a plain SQL table with four columns, that’s all. The important thing is that it unifies all Mailman resources into those four pieces of permission information.
Tying it all together - the auth proxy:
1: receives an inbound HTTP API request 2: determines (from the token that came with the request) the authenticated identity of the requesting user 3: determines (from the request URL/field params) which Mailman resource is being requested (i.e. a list or a domain or something else) 4: determines (from the request URL/field params) the type of activity that the requesting user wishs to carry out against that resource (create new, delete, rename, for example) 5: asks the authorization process “is this user allowed to carry out this type of activity against this resource?” 6: the authorization process has its own set of business rules for working out if a particular user is allowed to carry out the requested activity against the requested resource. It uses the permissions table to work out if user is allowed to access resource in the requested manner. 7: finally, if the authorisation process approves, then the request is carried out.
Phew!
Any questions welcome. I’m hoping to have working code to show before Pycon. I want to get it sufficiently complete such that it works when I first release it.
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/visser%40terena.o...
Security Policy: http://wiki.list.org/x/QIA9
-- Dick Visser Sr. System & Networking Engineer GÉANT Association, Amsterdam Office (formerly TERENA) Singel 468D, 1017 AW Amsterdam, the Netherlands Tel: +31 (0) 20 530 4488
GÉANT Association Networking. Services. People.
Learn more at: http://www.géant.org