Feat: SSO group sync (#7293)

* feat: Add settings for SSO group sync

* feat: Handle SSO group sync

* fix(SSO): Add default group only if it is the only one

When syncing SSO groups on first user creation,
the default group should not be added if there is
already another group synced by the IdP

* docs: Add SSO goup sync instructions

* fix: Run pre-commit hooks

* i18n(SSO): Wrap settings name and description

* docs(SSO): Fix links to allauth docs

* fix(frontend): Add SSO_GROUP_KEY option

* add unittests for SSO

* docs(SSO): Make hint for example comfiguration a tip

* docs(SSO): Describe relation between SSO sync and signup group

* fix(SSO): Avoid potential key error

* feat(SSO): Create mapped group if it does not exist

* docs(SSO): Describe how groups can be created during signup

---------

Co-authored-by: Oliver <oliver.henry.walters@gmail.com>

docs/docs/settings/SSO.md

@@ -4,13 +4,13 @@ title: InvenTree Single Sign On
 
 ## Single Sign On
 
-InvenTree provides the possibility to use 3rd party services to authenticate users. This functionality makes use of [django-allauth](https://django-allauth.readthedocs.io/en/latest/) and supports a wide array of OpenID and OAuth [providers](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html).
+InvenTree provides the possibility to use 3rd party services to authenticate users. This functionality makes use of [django-allauth](https://docs.allauth.org/en/latest/) and supports a wide array of OpenID and OAuth [providers](https://docs.allauth.org/en/latest/socialaccount/providers/index.html).
 
 !!! tip "Provider Documentation"
-    There are a lot of technical considerations when configuring a particular SSO provider. A good starting point is the [django-allauth documentation](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html)
+    There are a lot of technical considerations when configuring a particular SSO provider. A good starting point is the [django-allauth documentation](https://docs.allauth.org/en/latest/socialaccount/providers/index.html)
 
 !!! warning "Advanced Users"
-    The SSO functionality provided by django-allauth is powerful, but can prove challenging to configure. Please ensure that you understand the implications of enabling SSO for your InvenTree instance. Specific technical details of each available SSO provider are beyond the scope of this documentation - please refer to the [django-allauth documentation](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html) for more information.
+    The SSO functionality provided by django-allauth is powerful, but can prove challenging to configure. Please ensure that you understand the implications of enabling SSO for your InvenTree instance. Specific technical details of each available SSO provider are beyond the scope of this documentation - please refer to the [django-allauth documentation](https://docs.allauth.org/en/latest/socialaccount/providers/index.html) for more information.
 
 ## SSO Configuration
 
@@ -31,8 +31,8 @@ There are two variables in the configuration file which define the operation of
 
 | Environment Variable |Configuration File | Description | More Info |
 | --- | --- | --- | --- |
-| INVENTREE_SOCIAL_BACKENDS | `social_backends` | A *list* of provider backends enabled for the InvenTree instance | [django-allauth docs](https://django-allauth.readthedocs.io/en/latest/installation/quickstart.html) |
-| INVENTREE_SOCIAL_PROVIDERS | `social_providers` | A *dict* of settings specific to the installed providers | [provider documentation](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html) |
+| INVENTREE_SOCIAL_BACKENDS | `social_backends` | A *list* of provider backends enabled for the InvenTree instance | [django-allauth docs](https://docs.allauth.org/en/latest/installation/quickstart.html) |
+| INVENTREE_SOCIAL_PROVIDERS | `social_providers` | A *dict* of settings specific to the installed providers | [provider documentation](https://docs.allauth.org/en/latest/socialaccount/providers/index.html) |
 
 In the example below, SSO provider modules are activated for *google*, *github* and *microsoft*. Specific configuration options are specified for the *microsoft* provider module:
 
@@ -44,7 +44,7 @@ In the example below, SSO provider modules are activated for *google*, *github*
     Note that the provider modules specified in `social_backends` must be prefixed with `allauth.socialaccounts.providers`
 
 !!! warning "Provider Documentation"
-    We do not provide any specific documentation for each provider module. Please refer to the [django-allauth documentation](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html) for more information.
+    We do not provide any specific documentation for each provider module. Please refer to the [django-allauth documentation](https://docs.allauth.org/en/latest/socialaccount/providers/index.html) for more information.
 
 !!! tip "Restart Server"
     As the [configuration file](../start/config.md) is only read when the server is launched, ensure you restart the server after editing the file.
@@ -57,7 +57,7 @@ The next step is to create an external authentication app with your provider of
     The provider application will be created as part of your SSO provider setup. This is *not* the same as the *SocialApp* entry in the InvenTree admin interface.
 
 !!! info "Read the Documentation"
-    The [django-allauth documentation](https://django-allauth.readthedocs.io/en/latest/socialaccount/providers/index.html) is a good starting point here. There are also a number of good tutorials online (at least for the major supported SSO providers).
+    The [django-allauth documentation](https://docs.allauth.org/en/latest/socialaccount/providers/index.html) is a good starting point here. There are also a number of good tutorials online (at least for the major supported SSO providers).
 
 In general, the external app will generate a *key* and *secret* pair - although different terminology may be used, depending on the provider.
 
@@ -132,6 +132,31 @@ In the [settings screen](./global.md), navigate to the *Login Settings* panel. H
 
 Note that [email settings](./email.md) must be correctly configured before SSO will be activated. Ensure that your email setup is correctly configured and operational.
 
+## SSO Group Sync Configuration
+
+InvenTree has the ability to synchronize groups assigned to each user directly from the IdP. To enable this feature, navigate to the *Login Settings* panel in the [settings screen](./global.md) first. Here, the following options are available:
+
+| Setting | Description |
+| --- | --- |
+| Enable SSO group sync | Enable synchronizing InvenTree groups with groups provided by the IdP |
+| SSO group key | The name of the claim containing all groups, e.g. `groups` or `roles` |
+| SSO group map | A mapping from SSO groups to InvenTree groups as JSON, e.g. `{"/inventree/admins": "admin"}`. If the mapped group does not exist once a user signs up, a new group without assigned permissions will be created. |
+| Remove groups outside of SSO | Whether groups should be removed from the user if they are not present in the IdP data |
+
+!!! warning "Remove groups outside of SSO"
+    Disabling this feature might cause security issues as groups that are removed in the IdP will stay assigned in InvenTree
+
+### Keycloak OIDC example configuration
+
+!!! tip "Configuration for different IdPs"
+    The main challenge in enabling the SSO group sync feature is for the SSO admin to configure the IdP such that the groups are correctly represented in in the Django allauth `extra_data` attribute. The SSO group sync feature has been developed and tested using integrated Keycloak users/groups and OIDC. If you are utilizing this feature using another IdP, kindly consider documenting your configuration steps as well.
+
+Keycloak groups are not sent to the OIDC client by default. To enable such functionality, create a new client scope named `groups` in the Keycloak admin console. For this scope, add a new mapper ('By Configuration') and select 'Group Membership'. Give it a descriptive name and set the token claim name to `groups`.
+
+For each OIDC client that relies on those group, explicitly add the `groups` scope to client scopes. The groups will now be sent to client upon request.
+
+**Note:** A group named `foo` will be displayed as `/foo`. For this reason, the example above recommends using group names like `appname/rolename` which will be sent to the client as `/appname/rolename`.
+
 ## Security Considerations
 
 You should use SSL for your website if you want to use this feature. Also set your callback-endpoints to `https://` addresses to reduce the risk of leaking user's tokens.

docs/docs/settings/global.md

@@ -37,6 +37,10 @@ Change how logins, password-forgot, signups are handled.
 | Enable registration | Boolean | Enable self-registration for users on the login-pages | False |
 | Enable SSO | Boolean | Enable SSO on the login-pages | False |
 | Enable SSO registration | Boolean | Enable self-registration for users via SSO on the login-pages | False |
+| Enable SSO group sync | Boolean | Enable synchronizing InvenTree groups directly from the IdP | False |
+| SSO group key | String | The name of the groups claim attribute provided by the IdP | |
+| SSO group map | String (JSON) | A mapping from SSO groups to local InvenTree groups | {} |
+| Remove groups outside of SSO | Boolean | Whether groups assigned to the user should be removed if they are not backend by the IdP. Disabling this setting might cause security issues | True |
 | Enable password forgot | Boolean | Enable password forgot function on the login-pages.<br><br>This will let users reset their passwords on their own. For this feature to work you need to configure E-mail | True |
 | E-Mail required | Boolean | Require user to supply e-mail on signup.<br><br>Without a way (e-mail) to contact the user notifications and security features might not work! | False |
 | Enforce MFA | Boolean | Users must use multifactor security.<br><br>This forces each user to setup MFA and use it on each authentication | False |