bryan.kartzman@yu.edu writes:

I would like to create/pre-populate all the postorius usernames for our list owners/list moderators using their university net username. Is there a way to do that?

You can create Django users via the Django admin interface (typically the ".../admin" sibling to the ".../postorius" and ".../hyperkitty" URLs. It shouldn't be too hard to automate this, but I don't know of such a script. Django channels might be a better place to ask for that.

But after that things may get complicated. Are you migrating from an existing list server and want to link the new users to existing lists? I think this can be done as long as you link the appropriate owner addresses to each user. Hopefully those are algorithmically related to the network login (ie, address = username@domain).

Also, if by "network login" you mean a SSO protocol such as SAML, you can populate users directly from a service provider such as Shibboleth. There's a well-known protocol called REMOTE_USER that Django participates in. There are a couple of speed bumps you may run into, but it's hard to be specific without more information on your particular situation.

Steve

bryan.kartzman@yu.edu writes:

will do this. The university does use SSO for many applications and I was asked by upper management of the IT department to try and implement it here. I'm still trying to understand your reply to my SSO question from last week (my SSO knowledge is limited and I'll have to read up on Shibboleth, SAML, as well as Django) so for now I'm thinking to not use SSO

If they want to use it, pass the buck to them. I'm happy to help with the Mailman side (on a time-available basis or as a paid consultant -- time available is probably a much better deal, though!) But I can't know what the system in use is, so maybe you should get them to write an outline of the system (what software, what requirements, what ID-related attributes are available).

then transition to SSO later.

I don't think that will be a problem technically, as long as the user ids are the same for the same people. There will be UX issues though in the configuration I use. I think people will accept them quickly, but the UX will be different, which makes folks nervous if you don't warn them and explain why it's OK.

If you have any pointers as to where to read up on SSO, SAML, Shibboleth and also on Django please point me in the right direction.

For django, search "site:djangoproject.com REMOTE_USER". For shibboleth, the relevant documentation is on the atlassian site. Here's the main documentation for the "service provider" component (this is the part that Postorius would be using indirectly): https://shibboleth.atlassian.net/wiki/spaces/SP3/overview search there for "REMOTE_USER" for the most relevant documentation.

The SAML protocol is above our pay grade. :-) There's an introduction to the SAML architecture linked from the service provider documentation. That's way more than you need for this task, I think, so just skim it. Another guy did the Shibboleth config, so I'm a little fuzzy on this, but again I think that's mostly IT/NOC responsibility. (IIRC the main thing was getting the ID provider credentials and our host certs from the NOC, you can't generate those yourself!) The parts that hook into mailman are a list of translations of ID attributes to Apache variables, some email addresses for error reporting, and in Apache some translations of Apache variables to HTTP headers.

But you need to make sure it's SAML. I'm no expert on this stuff, but it seems like there are a bunch of these protocols, like OpenID and OAuth2 out there. Django knows how to do those, too, but we need to know which one!

Steve

bryan.kartzman@yu.edu writes:

It seems Microsoft Azure uses SAML2 authentication. When you say "(what software, what requirements, what ID-related attributes are available)" -- they just

Nobody ever stops at "just". ;-)

want them to authenticate to the mailman listserve using AZURE. What attributes besides username would have to be passed to Mailman?

The only attribute *needed for authentication* is username. But users are unlikely to be satisfied, and the straightforward implementation that I'm using has a number of implications that happen to work for my client, but I'm pretty sure would not be satisfactory in some other environments.

1. Users in my environment expect their profiles (display name, time zone) to be populated. (I haven't figured out how to do the latter, but it's a company with overseas offices, "that's the server's time zone" is acceptable.) Lack of first name, last name was considered a showstopper, though. In your environment there may be other attributes you'd like to add, but I think in stock Mailman 3 those (plus email, see point #2) those are all the attributes you would like to populate from the ID provider.

2. Owners and moderaters *need* their emails in the profile to be linked to their existing lists migrated from an existing Mailman 2 site (and maybe to future lists they admin, I haven't checked in detail). But confirming an email address is an annoyance you'd probably like to avoid.

3. The REMOTE_USER approach we use authenticates on every request, before the login screen is invoked. This means that superusers known to the network can't have a separate account; you need to give their personal users superuser privilege. This doesn't matter in my environment; the lists are used mostly for customer service, the admins with superuser normally don't interact with lists, so this actually increases accountability. (I don't think there's a "sudo" or "drop privileges" feature in Django.) This wouldn't be desirable in my university environment, as many of the superusers are faculty members who teach classes and supervise lists for their classes.

So, yeah, all you *need* is the username, but I'm willing to bet you will be askeed to deal with some of those other issues.

And again, the only SAML Service Provider I know how to configure is Shibboleth.

Steve

bryan.kartzman@yu.edu writes:

Just to let you know, there is a maintained SAML2 plugin available on github (https://github.com/grafana/django-saml2-auth) that I was able to install and get to work with AZURE SSO.

There are multiple ways to solve this problem. My employer wanted a host-wide solution so they chose Shibboleth.

Some day I'll go out and collect the ones I can find and document them (in summary form: source site, recency of stable version, recency of maintenance, etc).

Steve