> ## Documentation Index > Fetch the complete documentation index at: https://docs.chainloop.dev/llms.txt > Use this file to discover all available pages before exploring further. # Automatic provisioning of user roles and groups This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing). Chainloop platform can be configured to automatically onboard users to specific organizations and user groups by leveraging either static or dynamic provisioning through Single Sign-on (OIDC). ## Static provisioning ### Users and groups Static provisioning is useful in scenarios where **all** logged-in users should be automatically added to an organization with a specific role, and optionally, added to one or more groups. To enable this behaviour, add this configuration to the `backend` section in your [Platform deployment](/guides/deployment/platform#step-2-deploy-platform-chart) `values.yaml`: ```yaml theme={"dark"} backend: # ... autoOnboarding: enabled: true static_config: specs: - name: acme-corp # organization name where all users will be joined role: ORG_MEMBER # default role for new users. Other possible values: ORG_ROLE_ORG_OWNER, ORG_ROLE_ORG_ADMIN, ORG_ROLE_ORG_VIEWER groups: # user group names - name: compliance-team - name: development-team ``` In this example configuration, all logged-in users will be automatically added to `acme-corp` with the `OrgViewer` role. If the user already existed with a different role, it will be kept. Additionally, they will be added to the `compliance-team` and `development-team` teams. Note that existing user memberships will remain unchanged. ### Instance Administrators You can also configure instance administrators by providing a `instance_admin_spec` in the `static_config` section. ```yaml Platform Chart values.yaml theme={"dark"} backend: auto_onboarding: enabled: true static_config: instance_admin_spec: rules: - "user1@example.com" # Specific user - "@mydomain.com" # All users in the domain ``` These administrators will be able to create organizations even if the `restrictOrgCreation` flag is set to `true` in the Chainloop Controlplane. Learn more in this [guide](/guides/deployment/guides/restrict-org-creation). ## Dynamic provisioning through Single Sign-on (OIDC) In this scenario, user membership will become **managed** by the external Identity Provider configuration. Existing membership will be overridden by the incoming configuration inferred from the OIDC token claims. Follow these steps to configure auto-onboarding based on user claims. ### Configuring your IDP to provide group claims Make sure user OIDC tokens come with a `groups` claim. You'll need to check your provider configuration options. For example, Azure Entra ID provides the option through the [Enterprise Applications SSO configuration](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims#add-group-claims-to-tokens-for-saml-applications-using-sso-configuration). entra groups Check [How to configure Azure for SSO](./oidc-ad) for more information. ### Configuring Chainloop platform to parse `groups` claims In your chart `values.yaml` file, add this snippet to your `backend` section: ```yaml theme={"dark"} backend: # ... autoOnboarding: enabled: true dynamic_config: sync_mode: ADDITIVE # (1) groups_pattern: "chainloop_{ORG_NAME}_{GROUP_NAME}" # (2) default_role: ORG_MEMBER # (3) ``` This configuration will be applied to parse all groups claim coming in the OIDC token (it can have multiple values) * (1) `sync_mode`: It can take two values: `ADDITIVE` (default) and `MANAGED`. In the the fault configuration (ADDITIVE), users will be provisioned to the orgs and groups mapped from claims, but existing group and org memberships will be kept. In `MANAGED` mode, however, only org and group membership from SSO claims will be considered, and others will be removed. * (2) `groups_pattern`: this is the pattern that group claims should follow. Reserved placeholders `{ORG_NAME}` and `{GROUP_NAME}` will be mapped to the actual values coming in the claims. Note that both are mandatory, and the claim will be ignored if (1. it doesn't match the pattern, or 2. it doesn't provide both org and group names). For example, the above pattern will match: * `chainloop_acme-corp_developers` * `chainloop_acme-corp_org-viewer` Another example, this pattern `#{GROUP_NAME}@{ORG_NAME}#` will match: * `#developers@acme-corp#` * `#org-admin@acme-corp#` * (3) `default_role`: it will be used as the default role when joining users to an organization. #### Using dynamic configuration to provide a role instead of a group The above configuration can also be used to map Organization roles instead of user groups. The following "groups" are reserved and will be considered org roles instead: * `org-owner` will be mapped to the Org Owner role in the organization. * `org-admin` will be mapped to the Org Admin role. * `org-viewer` to Org Viewer. * `org-member` and `org-contributor` will be mapped to Org Member and Org Contributor (enabling [project-level RBAC](../../../reference/rbac)). * `admin` will be identified as the instance admin role if organization is `instance`, allowing users to create organizations even if the `restrictOrgCreation` flag is set to `true` in the Chainloop Controlplane. See the [Restrict organization creation to specific users](/guides/deployment/guides/restrict-org-creation) guide for more information. ### Requiring at least one entitlement to access the system As stated at the beginning of the section, Dynamic provisioning can set user in a managed state. Information coming from `groups` claim will take precedence. If the setting `sync_mode` is set to `MANAGED`, at least one matching entitlement (group or role) in group claims is needed to allow users to access the system. If that's not the case, users will be blocked from accessing the system. For this process to work, two settings must be configured, one in the chainloop Helm chart and another in the platform one. In Chainloop, you need to enable the `allowlist` feature with `allowDbOverrides` set to `true` and optionally provide a custom message to be shown to the user. ```yaml theme={"dark"} # In Chainloop Helm chart controlplane: ... auth: allowlist: allowDbOverrides: true customMessage: "please contact your administrator to request access" # this message will be shown to deactivated users through UI and CLI ``` In Chainloop platform Helm chart, make sure you set the `sync_mode` flag to `MANAGED` in the `autoOnboarding` section. ```yaml theme={"dark"} # In Chainloop platform backend: # ... autoOnboarding: enabled: true dynamic_config: sync_mode: MANAGED # ... ``` Make sure you understand and test carefully these settings before enabling Dynamic Provisioning