> For the complete documentation index, see [llms.txt](https://doc.dastra.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.dastra.eu/en/features/settings/scim.md). # SCIM On this page you will learn how to configure SCIM within Dastra using Microsoft Entra ID (formerly Azure Active Directory) ### How it works SCIM (System for Cross-domain Identity Management) is an open standard for automating user provisioning. The SCIM protocol acts as an intermediary, collecting user identity data from identity providers (Microsoft Entra ID, Google Workspace, Okta...) and communicating it to service providers (such as Dastra) who need the credentials. {% hint style="warning" %} The SCIM feature is reserved for customers on an **Enterprise plan.** [See our pricing page](https://www.dastra.eu/en/pricing) {% endhint %} {% hint style="info" %} We strongly recommend that you first [set up SSO](/en/features/settings/single-sign-on-sso.md) with the **"Force for all users" option enabled**. {% endhint %} ### How do I configure SCIM with Microsoft Entra ID? Dastra users can be added, deleted and modified using SCIM 2.0. You define groups in Entra ID and Dastra synchronizes those users automatically — no manual intervention required. #### 1. Sign in to the Microsoft Entra portal Go to and sign in with an administrator account. #### 2. Navigate to "Enterprise applications" In the left-hand menu, click **Entra ID** > **Enterprise applications** > **All applications**. #### 3. Click "New application" At the top of the application list, click **New application**.
#### 4. Create your own application On the "Browse Microsoft Entra App Gallery" page, click **+ Create your own application**. #### 5. Name and configure your application In the panel that opens: 1. Enter a name for your application (e.g. **Dastra SCIM**) 2. Select **"Integrate any other application you don't find in the gallery (Non-gallery)"** 3. Click **Create** #### 6. Open the provisioning configuration On the **Overview** page of the newly created application, click **"3. Provision User Accounts"** or click **Provisioning** in the left navigation menu. #### 7. Retrieve the SCIM URL and token from Dastra Before configuring Entra, get your SCIM credentials from Dastra. **Log in to Dastra** as an owner. Go to **Organisation Settings** >[ **Single Sign On**](https://app.dastra.eu/general-settings/sso) > **SCIM**
Click the **Configure** button to create a new SCIM configuration.
SCIM configuration creation modal in Dastra

Select the target workspace and the default role for new users

Select the **workspace** to synchronize (teams and users will be automatically provisioned there) and the **default role** assigned to new users. Roles can still be modified locally by Dastra administrators. Click **Save**, then **copy the SCIM URL and authentication token** displayed. {% hint style="info" %} Dastra supports synchronizing **one workspace per organization** via SCIM. {% endhint %} #### 8. Configure automatic provisioning in Entra Back in Entra, on your application's provisioning page: 1. Set **Provisioning Mode** to **Automatic** 2. Under **Admin Credentials**, fill in: * **Tenant URL**: the SCIM URL copied from Dastra * **Secret Token**: the authentication token copied from Dastra
3. Click **Test Connection** to verify the connection 4. Click **Save** If you encounter an error during the connection test, check that the SCIM feature is enabled on your subscription. [Contact support if needed](/en/commencer/support/request-support.md) #### 9. Activate provisioning Once the configuration is saved, activate provisioning by setting the status to **On** and clicking **Save**.
#### 10. Add users and/or groups In the application navigation menu, click **Users and groups**, then assign the Entra users or groups you want to synchronize with Dastra. ### Let your users log in You should see your Entra directory accounts automatically synchronized in Dastra. If SSO is not configured and enforced, users will need to reset their password for their first login. If SSO is enabled and forced for all users, they will be automatically redirected to your identity provider's login form (Microsoft Entra ID, Google Workspace, Okta…). ### SCIM Synchronization Behavior and Limitations #### User Lifecycle Management **User Disabled in Entra ID** When a user is disabled in Entra ID: * Their profile is **anonymized in Dastra** * If the user is later re-enabled: * A **new user account is created** * The previous anonymized account is not restored *** **Full Deletion in Entra ID** When a user is permanently deleted from Entra ID: * Their profile is **fully anonymized in Dastra** * All past actions are **preserved** * The user appears as **"deleted user"** **Impact on related data:** * Linked objects (e.g. processing activities, risks, requests, etc.) are **not deleted** * Relationships (e.g. owner, assignee) are **preserved** * Only the user’s identity is anonymized *** #### Group (Team) Management **Group Removal in Entra ID** If a group is removed in Entra ID: * The corresponding **team is deleted in Dastra** * **User accounts remain active** * No impact on individual users *** #### Mapping and Synchronization Scope **Groups and Workspaces** * SCIM supports synchronization of **multiple groups** * Current limitation: * Only **one workspace per organization** can be synchronized * Multi-workspace synchronization is **not supported** *** **Supported Attributes** Currently, Dastra synchronizes: * for users: login identifier, first and last name, e-mail address, active status, language and postal address (country, city, postal code, region) — see [Which attributes and claims are supported?](#which-attributes-and-claims-are-supported) for the full list; * for groups: the **name (`displayName`)**, the group identifier (`externalId`) and the **members**. Not supported at this stage: * Mapping to **organizational units** * The attributes of the enterprise extension (organization, department, employee number, manager…): identity providers send them by default, Dastra accepts them without storing them. > This could be supported in the future via a specific attribute containing a reference identifier compatible with Dastra. *** #### Local Management in Dastra After SCIM synchronization: * Administrators can still: * **modify roles** * **adjust permissions** * Fine-grained access control remains **manageable locally in Dastra** *** #### Licensing Impact * SCIM synchronization is limited by: * the **number of users included in your subscription** * If the quota is exceeded: * The SCIM server returns a **`403` error** with the `limitExceeded` type * Additional users are **not provisioned** *** ### SCIM endpoints and discovery The Dastra SCIM API exposes the standard SCIM 2.0 endpoints, all served under your SCIM URL and authenticated with the SCIM token (requests without a valid token receive a `401`): | Endpoint | Purpose | | --------------------------- | ------------------------------------------------------------- | | `/v2/Users` | Create, read, update (PATCH) and delete users | | `/v2/Groups` | Create, read, update (PATCH) and delete groups (Dastra teams) | | `/v2/ServiceProviderConfig` | Declares the capabilities of the SCIM service | | `/v2/ResourceTypes` | Lists the resource types (User, Group) | | `/v2/Schemas` | Attribute-level definition of each supported schema | Updates go through `PATCH`; replacing a whole resource with `PUT` is not supported. A successful creation (`POST`) returns `201` with a `Location` header and a `meta.location` attribute giving the URL of the new resource. The three **discovery endpoints** (RFC 7644 §4) are read-only. Identity providers and SCIM connectors (Microsoft Entra ID, Okta, custom connectors…) probe them to build the attribute schema automatically — no manual schema file needed. `/v2/Schemas` describes exactly the attributes Dastra reads and writes: it is the authoritative list, and an attribute absent from it is ignored by the synchronization. `ServiceProviderConfig` also answers on the common aliases `/v2/ServiceProviderConfigs` and `/v2/ServiceProviderConfiguration`, since connectors disagree on its name. Capabilities declared by `ServiceProviderConfig`, matching the actual behavior of the API: * **Supported**: PATCH operations, filtering (see the limitation below). * **Not supported**: bulk operations, sorting, etags, password change. #### Filtering A filter holds **a single condition**, with the `eq` (equal) or `ne` (not equal) operator, on one of these attributes: | Resource | Filterable attributes | | -------- | ---------------------------------------- | | Users | `userName`, `externalId`, `emails.value` | | Groups | `displayName`, `externalId` | Example: `filter=userName eq "jane.doe@company.com"`. Attribute names are case-insensitive. {% hint style="info" %} Dastra never answers a filter it cannot evaluate exactly. Another operator (`co`, `sw`, `gt`…), another attribute, or several conditions combined with `and` / `or` return a `400` error of type `invalidFilter` that names the problem. {% endhint %} #### PATCH operations `PATCH` accepts the three forms sent by identity providers: an operation with a `path` and a simple value, an operation with a `path` and an object value, and an operation without `path` whose value lists the attributes to change. The `add`, `replace` and `remove` operations are supported. * **Users** — the attributes listed by `/v2/Schemas` are applied. Attributes Dastra does not store (enterprise extension, phone numbers, title…) are accepted and ignored, so that the default mappings of Microsoft Entra ID and Okta work without changes. `userName` and the e-mail address cannot be removed. Setting `active` to `false` deactivates the user, as described above. * **Groups** — `displayName` and `externalId` can be changed. Members can be added (`add`), replaced as a whole (`replace`) or removed (`remove`), either all at once or one by one with the path `members[value eq ""]`. A user that does not belong to your organization is reported as not found (`404`). #### Errors Errors follow the SCIM format (RFC 7644 §3.12): a JSON body with `status`, `scimType` and a `detail` message that says what was refused. | Code | When | | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `400` | Invalid request: missing or malformed value (`invalidValue`), unsupported filter (`invalidFilter`), unknown path (`invalidPath`), attribute that cannot be removed (`mutability`)… | | `401` | Missing or invalid SCIM token | | `403` | User quota of your subscription reached (`limitExceeded`) | | `404` | Resource not found, or not part of your organization | | `409` | A user or group with the same identifier already exists (`uniqueness`) | *** ## Frequently Asked Questions ### What is the role of SCIM in Dastra? SCIM is the **automated provisioning channel** between your enterprise directory (Entra ID, Okta, Google Workspace…) and Dastra. Its role is complementary — and distinct — from SSO: | | SSO | SCIM | | ---------------- | ----------------------- | --------------------------------------- | | **Role** | Authentication (login) | User lifecycle management | | **Trigger** | User login | Action in the IdP (add, update, remove) | | **What it does** | Verifies identity | Creates, updates, deactivates accounts | | **Protocol** | SAML 2 / OpenID Connect | SCIM 2.0 (HTTP REST + JSON) | With SCIM, you no longer need to manually create accounts in Dastra or revoke them when someone leaves — your directory remains the **single source of truth** for identity management. {% hint style="info" %} SCIM manages **who exists** in Dastra. SSO manages **how those people log in**. The two are independent but combine ideally: provision via SCIM, authenticate via SSO. {% endhint %} *** ### What is the expected overall process for provisioning and deprovisioning? #### Provisioning (account creation) When a user or group is assigned to the Dastra application in your IdP: 1. The IdP sends a **`POST /scim/v2/Users`** request to the Dastra SCIM endpoint 2. Dastra creates the account with the default role set in your SCIM configuration 3. The user is added to the target workspace 4. If SSO is enabled and enforced, the user can log in immediately without a password #### Updates Any profile change in the IdP (name, email, language, address) triggers a **`PATCH /scim/v2/Users/{id}`** request that updates the corresponding account in Dastra. A change of group membership triggers a **`PATCH /scim/v2/Groups/{id}`** request that adds or removes the members of the corresponding team. #### Deprovisioning (deactivation / deletion) | Action in the IdP | SCIM request | Effect in Dastra | | ------------------ | ----------------------------- | -------------------------------------------- | | User disabled | `PATCH` (`active: false`) | Profile **anonymized** | | Permanent deletion | `DELETE /scim/v2/Users/{id}` | Profile **fully anonymized**, data preserved | | Group removed | `DELETE /scim/v2/Groups/{id}` | Team deleted, users unaffected | {% hint style="warning" %} Re-enabling a previously anonymized user creates a **new account** — the history of the old account is not restored. {% endhint %} *** ### Which attributes and claims are supported? #### SCIM attributes synchronized (provisioning) During synchronization, Dastra reads the following SCIM 2.0 attributes. `/v2/Schemas` returns the same list. **Users** | SCIM attribute | Field in Dastra | Required | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------- | | `userName` | Login identifier, unique in your organization (usually the e-mail address) | ✅ Yes | | `emails` | E-mail address — Dastra keeps one address: the entry flagged `primary`, otherwise the first one | ✅ Yes | | `name.givenName` | First name | Recommended | | `name.familyName` | Last name | Recommended | | `active` | Active / inactive status | ✅ Yes | | `locale` | Language (e.g. `en`, `fr-FR`) | Optional | | `address` | Country (two-letter code), city, postal code, region — a single address | Optional | | `externalId` | Read-only: always returns the same value as `userName`. It can be used in a filter; a value sent by the identity provider is ignored | — | | `nickName` | Accepted at creation, never returned | Optional | **Groups** | SCIM attribute | Field in Dastra | Required | | -------------- | ----------------------------------------- | -------- | | `displayName` | Team name (30 characters maximum) | ✅ Yes | | `externalId` | Group identifier in the identity provider | Optional | | `members` | Team members (Dastra user identifiers) | Optional | {% hint style="info" %} Dastra keeps a single provisioning identifier per user, `userName`. Changing a user's `userName` in the identity provider updates it in Dastra; when the account was provisioned with its e-mail address as `userName`, the e-mail address follows the change. {% endhint %} #### SSO claims used at login When logging in, Dastra identifies the user via the email claim sent by the IdP. Both supported SSO protocols use the same property: | Protocol | Email claim used | Required scope | | -------------- | -------------------------------------------------------------------- | ---------------------- | | SAML 2 | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` | — | | OpenID Connect | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` | `openid profile email` | {% hint style="warning" %} The email address is the **linking key** between SCIM and SSO: the `userName` provisioned via SCIM must be **identical** to the email claim returned at SSO login. Any discrepancy will prevent account matching. {% endhint %} For the full SSO claim configuration, see the [Single Sign On (SSO)](/en/features/settings/single-sign-on-sso.md) page. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.dastra.eu/en/features/settings/scim.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.