Hello Mark, hello Stephen,
thank you very much for your very detailed explanations concerning the user management! I appreciate it very much!!!
@Mark: Your assumption is right:
I'm not sure what distinction you are making between PostgreSQL and Django-Framework. There are two separate and distinct users, Django users and Mailman core users. Information about both is in the PostgreSQL database. Django users are in the auth_user table and Mailman core users are in the user table, both in the public schema, although if you split the data into a mailman database and a mailmanweb database the auth_user table is in mailmanweb and the user table is in mailman. I have two databases, a mailman db and a mailman-web db with the two user tables (user and auth_user). I did not realize that the django users are stored in the auth_user table of the mailman-web db. So both "user databases" are in ProstgreSQL dbms...mailman core and django. I should refer to them as mailman core users and django users...that is clear to me now... :-)
@Stephen: your substantial remarks on social account providers are very helpful:
How will a social account provider (like oidc) linkage (in Django) fit in this concept? Will oidc-accounts be copied to the Django's user database (or PostgreSQL db) or is it an on-the-fly check against the oidc-provider? (I assume second option) What are the status-flags (staff status/superuser status/active status) of the linked oidc-accounts? (Can I specify the status flags?) I don't offhand know the answers to that, but I think logging in via a social account provider creates a Django user.. I can't speak for generic social accounts, but it definitely did that for a Shibboleth-based SSO setup. Just pass the login credentials provided by Shibboleth through to the social account stuff (verrrry carefully :-), and everything just works. Social auth gets the bare minimum information from the idP as far as I know (didn't look into it carefully). At least in my case all we got from Shibboleth was a display name (the personal name) and an email address (not even an verifiable auth token, they trusted their network that much). Users could set passwords but they didn't work (Django could only be accessed by users logged in to the network, and if you logged out, the request triggered by the redirect back to the login page would log you right back in again! Freaky...).
Now I know I have to connect our IdP first! This step should provide access to the WebUI/django for all users reigned by our IdP. In a second step I can set up according (selected) mailman core users and in a third step I assign these users to a list as admin/owner or member.(*)
(*) Maybe there needs to be adaptions to the status flags (is_superuser, is_staff, is_active) for the django users between step one and two - i will have to see for that...
Thank you again for your helpful input!
Chris