Make users superuser based on groups

[alextreme]

We notice that the groups_claim+sync_groups+sync_groups_glob_pattern options are being used more frequently, they work quite well.

However in expanding our own usage of SSO (@sjoerdie has set up a generic keycloak instance) we notice that our current way of dealing with OIDC groups causes a significant number of Django Groups in each of our components. This because the OIDC Groups are mapped 1-to-1 to a Django Group. This causes additional maintenance efforts and duplication of permission groups, with the consequences being: too little permissions / too many permissions / I'll just give everyone superuser permissions. Each component has out-of-the-box permission groups which are updated, but this will be unmaintainable if each OIDC integration generates groups with different names.

As such we propose a group_mapping JSON Field, similar to how the claim_mapping JSON field works. This should allow us to map a keycloak OIDC group name like 'openforms.maykin.test.beheer' to the (existing) Django Group 'Beheerders'. A user logging in that has the OIDC group 'openforms.maykin.test.beheer' should then be linked automatically to 'Beheerders'.

I suspect that some kind of globbing may also be useful to avoid complicating the group_mapping JSON, but discuss this with Sjoerd to ensure that what we introduce works well for our use case. Also note that Sjoerd is looking into using roles instead of groups for managing users in Keycloak, this may have an impact on this issue.

Internal Taiga #450

Tasks

Group mapping

• Add a group-mapping that allows to map OIDC groups to Django groups. It should be possible to map multiple OIDC groups to one Django group, and to map one OIDC group to multiple Django groups.
• Group-memberships in Django should be updated upon every login. This also means the removal of group-memberships that a user no longer have according the the OIDC mapping. This can happen when you change the mapping or when you change the group in the OIDC provider.

The above tasks are no longer needed. We'll arrange group mappings in the OIDC provider, where it should be.

Superusers

• Add a comma separated field that holds special "superuser" groups. Users that login with OIDC and have one of these groups, should be marked as superuser.
• If a user, upon login, doesn't have one of these groups (and the field is not empty), the superuser flag should be removed.
• If this field is empty, the superuser flag should never be influenced (so you can set it manually, without it disappearing after logging in again)

Example

Superuser-groupclaims:

Supplier.Test.ProductX.Superuser, Supplier.Test.Superuser
# Everyone that has one (or multiple) of these group claims, will get the superuser flag set.

[joeribekker]

Added specific tasks and worked out the superuser case.