Sorry I meant SAML looks similar to JWT but XML based.

On 18 Feb 2015, at 10:45 am, Dick Visser <visser@terena.org> wrote:

sorry meant to sent to list, just did that now

On Wed, Feb 18, 2015 at 12:42 AM, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:

Hi Dick,

If you re-post as a reply to the mailing list I can send a reply there.

thanks

as

On 18 Feb 2015, at 10:40 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 an 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

-- 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