Overview

Blindata can act as a SCIM 2.0 service provider so Microsoft Entra ID (or another compatible identity provider) can create, update, and deprovision users and groups in a tenant.

SCIM is directory provisioning, not login. After users exist in Blindata, they still sign in with the authentication methods you already configured, such as Microsoft Entra SSO . Provisioning does not enable SSO, does not change the Microsoft sign-in allow-list.

Each Blindata tenant has its own SCIM endpoint. One Entra provisioning job targets one Blindata tenant.

How Provisioning Fits With Access Control

Provisioned users are created with no permissions.

Access in Blindata then comes from:

• Stewardship role assignments — granted when the user is a member of a provisioned group. See Stewardship Roles .
• Team policies — granted when that same Entra group also matches an existing team. Members get full team privileges (Read, Write, Propose, and Approve). See Team Policies .
• Stewardship responsibilities — still assigned in Blindata (user + role + resource). SCIM never creates or deletes responsibilities.

Plan Entra groups around the stewardship roles and teams you already maintain, then let membership drive assignments.

Configure the SCIM Connection in Blindata

1. Open Settings and choose SCIM Provisioning from the overflow menu (the same menu as Search Settings and OAuth Clients).
2. Copy the Tenant URL. It is built by Blindata and has the form {origin}/scim/v2/tenant/{tenantUuid}. Do not invent this URL or put the tenant name in the path.
3. Click Generate token.
4. Select a provisioning audit principal: an active user associated with the current tenant. SCIM create, update, and delete events are recorded as this user, not as the administrator who issued the token.
5. Copy the Secret Token immediately. It is shown only once. Blindata stores a hash; you cannot retrieve the plaintext later.
6. Paste the Tenant URL and Secret Token into Entra (see the next section).

The connection page also shows:

• Whether SCIM is Configured (a token exists) or Not configured.
• Who generated the token and when.
• The current audit principal.
• When a SCIM client last authenticated successfully.
• A rotation pending warning while the previous token is still accepted.

Rotate or revoke the token

Rotate when you need a new secret or a different audit principal. The previous token keeps working until Entra authenticates once with the new token, or until the rotation grace window expires (one hour by default). Update Entra as soon as you copy the new token so provisioning does not stall.

Revoke turns SCIM off for the tenant: provisioning requests fail until you generate a new token and configure it in Entra.

The token does not expire on its own. Treat it as a long-lived secret.

Configure Microsoft Entra ID

Use a non-gallery enterprise application with automatic provisioning.

1. Create or open the enterprise application that will provision this Blindata tenant. You can reuse the same application you use for SSO; assignment then covers both sign-in and provisioning.
2. Open Provisioning and select Automatic.
3. Paste the Blindata Tenant URL and Secret Token, then run Test Connection.
4. Enable Users and Groups mappings.
5. Map the Entra user object ID to SCIM externalId. Do not leave the default mailNickname → externalId mapping.
6. Assign the users and groups that should be provisioned, then start provisioning.

User Mapping

Passwords sent by Entra are ignored. Provisioned users are not application (API) users, and Blindata does not turn on basic password login as a side effect of SCIM.

Unmapped attributes such as manager, title, or department do not fail the job. Simple string extras can be stored on the user; complex values (for example manager) are ignored.

User lifecycle

• Create. Blindata creates the user on the path tenant with Application Scope NONE. Existing users in the same tenant are adopted (matched by username or email, then updated). Username or email already owned in another Blindata tenant returns a conflict (HTTP 409).
• Disable. active=false deactivates the user. They cannot log in, but SCIM can still GET them.
• Delete. SCIM delete hides the user from the protocol (later GET/filter returns 404). Blindata may keep the inactive row. A later create with the same email or externalId resurrects the same Blindata UUID.
• Hard delete from the Blindata Users page is separate. After a hard delete, a new Entra create produces a new UUID.

Application users are excluded from the SCIM user list.

Groups, Stewardship Roles, and Teams

SCIM Groups are not a third catalog object. Each provisioned Entra group is bound to a stewardship role, and optionally to a team that already exists with the same name.

Binding rules

When Entra creates a group:

1. Blindata looks up a stewardship role whose name matches the group displayName (case-insensitive). If none exists, it creates a stub role with that name and empty permissions. Admins should then edit the role in Stewardship so it grants the intended catalog access.
2. Blindata looks up a team whose name matches the same displayName. If a unique team exists, it is bound. Teams are never created by SCIM. If you want team access, create the team in Blindata first with the same name as the Entra group.
3. Entra’s group object ID is stored as externalId on the bound role and, when present, on the bound team. After that, membership and delete use externalId, not the name.
4. The SCIM Group id is the stewardship role UUID. Only roles that still have an externalId are exposed as groups.

The same Entra object ID may sit on one team and one role (dual bind). It cannot be reused on a second role or a second team.

If more than one role or more than one team shares the display name, group create fails with a conflict until the duplicates are cleaned up. Team and role names are unique case-insensitively within a tenant.

Membership

Adding a user to the Entra group:

• Assigns the user to the bound stewardship role.
• If a team is bound, grants a full team policy (Read, Write, Propose, Approve). Existing policies for that user on the team are left as they are.

Removing a user from the group drops that role assignment and that team policy entirely. Blindata does not distinguish SCIM members from members added in the UI: a remove or group delete affects all members of the bound objects.

Only user members are supported. Nested groups are rejected. Members are resolved by Blindata user UUID, not by Entra object ID. If Entra adds a member that is not yet provisioned as a user, Blindata returns 404 so Entra can retry after the user is created.

GET Group returns the union of role assignees and team members.

Group updates and delete

• Changing the group display name renames the stewardship role. It does not rename the team name or team code.
• Deleting the group in Entra unprovisions the bind: externalId is cleared, all role assignments on that role are removed, and all team policies on a bound team are removed. The role and team rows remain. Stewardship responsibilities on resources are not deleted. After unprovision, GET Group returns 404.

Recommended setup pattern

1. In Blindata, create stewardship roles with the permissions and resource applicability you need. Name them exactly as the Entra groups that should drive those roles.
2. Optionally create teams with the same names if those groups should also control team-scoped access. Assign resources to the teams as usual.
3. In Entra, assign those groups to the provisioning application.
4. After the first sync, open the stub roles (if any were auto-created) and complete their permission matrix. Until you do, membership succeeds in Entra but users may still have no catalog access.

What SCIM Does Not Do

• Grant or change Application Scope or the tenant permission matrix. Manage those in User permissions .
• Create teams, team codes, or double-approval settings.
• Assign stewardship responsibilities on specific resources.
• Pre-bind Microsoft OIDC subjects. The first successful SSO login still creates that binding.
• Support nested groups, SCIM PUT, ETags, bulk operations, or advertising the Enterprise User schema.
• Combine with LDAP directory sync unless that combination has been explicitly tested.

Related Guides

• How to Manage Users
• How to Give Permissions to a User
• Team Management
• Stewardship Roles
• SSO With Microsoft Entra ID