Sorry I meant SAML looks similar to JWT but XML based. On 18 Feb 2015, at 10:45 am, Dick Visser <vis...@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.stu...@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 <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 an 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 > -- 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
