dlb-ml--- via Mailman-users writes:
I'm looking to see if there's any way to isolate the third-party login section and prevent local account sign in and sign up. This way, we can ensure that the people within our organization are using a stronger auth method that prioritizes MFA, rather than just username/password.
This is really a Django/allauth question. I strongly recommend you ask there. Maybe Mark knows more, but my own experience with it is limited, and the client specified the setup, I just implemented it.
I did see that there is the SOCALACCOUNT_ONLY option, as provided by allauth (https://docs.allauth.org/en/latest/socialaccount/configuration.html), but that broke any attempt to display the sign in page,
My experience was using Shibboleth to authenticate to Apache, require authenticated user for all Mailman and Django locations, and Apache would communicate the authenticated user ID directly to Postorius. You could visit the page, but because you were already authenticated, you had to log out to log in. But -- Catch-22 -- that access would go through Apache and log you in.
assuming [SOCIALACCOUNT_ONLY] is not supported with the current version of MM3.
AFAIK, there's no code in Postorius that's specific to processing authentication -- that's all done by Django or Django plugins, and controlled by the standard Django and allauth parameters. So it's not something Mailman is related to supporting. This is a question of what allauth, and possibly Django core, supports. It's possible that Mailman defaults to a configuration that messes up Django's support, but if so I would bet that somebody with deep knowledge of how allauth works could tell you how to get the effect you want.
Is my plan to modify the templates viable?
It's not clear what your goal is. If it's just to keep typical users on the straight and narrow, yes, that should work. But as far as I know, a competent user who is mischievous or malicious can probably craft requests to successfully access any locations that are not disabled in code or protected by the frontend webserver. Disabling the signup adapter will definitely make mischief much harder, but I can't promise it's impossible.
But if you have a SSO system with an organization-specific IDP or a database of 3rd-party accounts with Google or whatever, I would think you'd want to use that as the source of ground truth directly, as I described my experience above, rather than creating a separate credientials database in Django.
Given the discussions on disabling the anonymous subscription form, are the email commands a less spam-susceptible solution or are they just as vulnerable as the form?
The whole point of email commands was to allow anonymous signups (more precisely, pseudonymous signups tied to a mailbox). If you don't want "anonymous" signups, you don't want to enable the email commands.