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 <vis...@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.stu...@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 supermaillingl...@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.org > > 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 _______________________________________________ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
