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