Enforcing SSO and subscription options
Contrary to the messages I found in the archive, rather trying to delete or remove the social login portion of the sign in page, 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.
To do this, our plan is to block signups using "ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'" and to remove the portions of the login template such that the username/password/forgot password fields are removed, leaving just the button to our SSO instance. I'm anticipating that this should be sufficient to block username/password sign ins, and is resistant to page manipulation due to CSRF tokens, but I wanted to ask to see if there was a better way, like an official configuration (which I have not found yet). 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, and I'm assuming is not supported with the current version of MM3. Is my plan to modify the templates viable?
Additionally, because external users would not have access to their own dashboards within the web UI, and since we are planning on disabling anonymous subscriptions with "SHOW_ANONYMOUS_SUBSCRIBE_FORM=False", the only two viable ways to subscribe to a list for them would be:
- Send a request directly to the list owner or a superadmin to subscribe/unsubscribe the address
- Allow email commands to subcribe/unsubscribe users (i.e. $LISTNAME-join@$DOMAIN)
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?
Thanks
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.
Thank you for the reply. Ultimately, I ended up digging deeper into the allauth docs, per your suggestion, and I went a little bit further with the "SOCIALACCOUNT_ONLY" option. It turns out that the errors I were seeing were related to the sign up button referencing a view that didn't exist. I solved this in an admittedly ugly way, by removing the sign up button from the postorius and hyperkitty templates. This will make upgrades a pain, as I'll have to account for this in the future, but it appears to be exactly what I was looking for.
Thank you for your insight!
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.
Also, thank you for this. I figured this was the case, but I wanted to make sure.
via Mailman-users writes:
Thank you for the reply. Ultimately, I ended up digging deeper into the allauth docs, per your suggestion, and I went a little bit further with the "SOCIALACCOUNT_ONLY" option. It turns out that the errors I were seeing were related to the sign up button referencing a view that didn't exist.
You have to do this, I suspect (I am unsure that removing the reference from urls.py would protect you from A Sufficiently Smart Miscreant, and if it did you'd still get the error, so why not remmove the code and remove all doubt!)
I solved this in an admittedly ugly way, by removing the sign up button from the postorius and hyperkitty templates.
You do not have to do it this way. There is a search path for templates, and you can remove those buttons from copies stored in a directory earlier in the path. I use /etc/mailman3/templates/..., but they can go anywhere convenient that won't be overwritten by an upgrade. The worst that could happen is the copies get removed, and then you get the error, which you fix.
participants (2)
-
dlb-ml＠anl.gov -
Stephen J. Turnbull