SCIM 2.0 User Provisioning

cidaas implements SCIM 2.0 (RFC 7642, RFC 7643, RFC 7644) so external identity systems can provision users and groups into your cidaas instance using a standardized REST API.

Base URL: https://{your-domain}/user-scim-srv/v2

info

API reference

This page covers setup and integration concepts. For endpoint details, request/response schemas, and try-it-out examples, see the SCIM v2 OpenAPI reference.

How cidaas fits into SCIM

In SCIM terminology, cidaas acts as the Service Provider — the system that receives and stores provisioned identities.

	cidaas	Your integration
Role	Provisioning target (SCIM Service Provider)	SCIM client (e.g. your identity provider or custom integration)
Direction	Receives user and group changes	Pushes user and group changes to cidaas
Outbound sync	Not supported	Your responsibility

cidaas provides SCIM REST endpoints for identity providers that speak SCIM natively. It does not connect to HR systems, Active Directory, or other SCIM endpoints on its own, and it does not run synchronization workflows internally.

For custom integrations and orchestration, use the official cidaas User and Group APIs — typically via cnips.io, not SCIM.

Before you start

Complete these steps in your cidaas instance before connecting a SCIM client:

1. Configure SCIM mapping

Each cidaas instance requires a SCIM mapping that defines how SCIM attributes map to cidaas user fields and which group types are exposed.

In Trust Desk:

1. Open Providers → SCIM Mapping (/scimmapping).
2. Configure Group Strategy — select which group types are included in SCIM user responses and set a default group type for provisioned groups.
3. Configure Field Attributes — map each cidaas field to its SCIM attribute (for example email → emails.work.value, given_name → name.givenName).
4. Save the mapping.

Required roles: ADMIN, SECONDARY_ADMIN, SCIM_CREATE, or SCIM_READ (write access requires SCIM_CREATE).

Mapping rules:

• One cidaas field maps to exactly one SCIM attribute (and vice versa).
• Required SCIM attributes such as id, userName, and userType must be mapped.
• Complex SCIM attributes use canonical paths, for example:
  • emails.work.value
  • name.givenName
  • addresses.work.streetAddress
• Group membership in SCIM user responses is limited to the group types you select in Group Strategy.

Example mapping configuration:

{
  "_id": "SCIMMAPPING",
  "userAttsMapping": {
    "scimType": "user",
    "attributeMap": {
      "sub": "id",
      "family_name": "name.familyName",
      "given_name": "name.givenName",
      "email": "emails.work.value",
      "mobile_number": "phoneNumbers.mobile.value",
      "preferred_username": "userName"
    }
  },
  "groupMappingStrategy": {
    "groupsOfGrouptypes": ["CIDAAS_USERGROUP_TYPE", "ORGUNIT_TYPE"],
    "groupTypeSameAsGroup": false,
    "defaultGroupType": "ORGUNIT_TYPE"
  }
}

You can also manage mapping via the API:

Action	Method	Endpoint
Read mapping	GET	/user-scim-srv/v2/mapping
Save mapping	PUT	/user-scim-srv/v2/mapping

2. Create an OAuth 2.0 client

Create an application in cidaas with the Client Credentials grant and assign the SCIM scopes your integration needs.

Token endpoint: https://{your-domain}/token-srv/token

Scope	Purpose
cidaas:scim_read	Read users, groups, schemas, and service configuration
cidaas:scim_write	Create and update users and groups
cidaas:scim_delete	Delete users and groups

Send the access token as a Bearer token in the Authorization header on every SCIM request.

3. Configure your SCIM client

Point your SCIM client to:

https://{your-domain}/user-scim-srv/v2

Typical first steps for the client:

1. GET /ServiceProviderConfig — discover supported features and authentication
2. GET /Schemas and GET /ResourceTypes — discover the user and group schema for your instance
3. POST /Users or PATCH /Users/{id} — provision users
4. POST /Groups or PATCH /Groups/{id} — manage groups

User and group schemas are generated dynamically from your SCIM mapping and field setup — they are not fixed across instances.

API overview

Resource	Path	Operations
Service Provider Config	/ServiceProviderConfig	GET
Resource Types	/ResourceTypes, /ResourceTypes/{type}	GET
Schemas	/Schemas, /Schemas/{schemaID}	GET
Users	/Users, /Users/{userId}	GET, POST, PUT, PATCH, DELETE
Groups	/Groups, /Groups/{id}	GET, POST, PUT, PATCH, DELETE
Mapping (admin)	/mapping	GET, PUT

Supported features

Feature	Supported
PATCH	Yes
Filter (max. 25 results per query)	Yes
Bulk operations	No
Sort	No
ETag	No
Change password via SCIM	No

Typical integration flow

1. Configure SCIM mapping in Trust Desk.
2. Create an OAuth client with SCIM scopes.
3. Configure your identity provider or integration (for example your identity provider's enterprise application provisioning).
4. Set the SCIM base URL to https://{your-domain}/user-scim-srv/v2.
5. Run a test provisioning cycle (create, update, deactivate, delete).

Important: cidaas does not pull changes from external systems. Your SCIM client must push create, update, and delete operations to cidaas.

When to use SCIM vs. cnips.io

These are two separate integration paths. They are not interchangeable.

Use SCIM when

Your identity provider supports outbound SCIM provisioning and you need it to push users and groups into cidaas using the SCIM standard.

• API: /user-scim-srv/v2
• Requires: SCIM mapping in Trust Desk
• Scopes: cidaas:scim_read, cidaas:scim_write, cidaas:scim_delete

Use cnips.io when

You need synchronization, transformation, or workflows between cidaas and other systems (HR, ERP, Microsoft 365, and other business systems).

With cnips.io you do not use SCIM. Pipelines call the official cidaas User and Group APIs directly — the native REST APIs documented under User Management (for example user creation, update, group membership, bulk read/write). This avoids SCIM schema mapping, works with the native cidaas data model, and supports flexible field mapping in the pipeline.

	SCIM	cnips.io
API	SCIM 2.0 (/user-scim-srv/v2)	Official cidaas User & Group APIs
Typical source	Identity provider	HR systems, ERP, webhooks, custom sources
Mapping	Fixed 1:1 via SCIM mapping	Flexible in pipeline — native cidaas fields
Workflows	CRUD only	Approvals, validation, notifications
SCIM mapping required	Yes	No

Examples well suited for cnips.io (not SCIM): employee onboarding, email change with approval, absence management, multi-system sync.

For one-time bulk migration without SCIM, cidaas also provides bulk user APIs at user-ext-srv/bulkread/users and user-ext-srv/bulkwrite/users.

Limitations

Be aware of the following when planning a SCIM integration:

1. Schema differences — cidaas uses a flexible, OIDC-oriented user model. SCIM uses nested structures for emails, phone numbers, and addresses. Mapping must be configured explicitly; unmapped SCIM data is not stored.
2. No bulk support — large initial migrations should use the official bulk User APIs or cnips.io pipelines (not SCIM).
3. Groups at scale — cidaas groups can contain very large numbers of members. Update group membership via user PATCH operations rather than expecting full member lists on group resources.
4. Custom fields — you may need to add custom cidaas fields and include them in SCIM mapping to capture all attributes from your source system.
5. No outbound SCIM — cidaas cannot connect to external SCIM endpoints as a client. All provisioning flows into cidaas.

Support

• Documentation: docs.cidaas.com
• Support: support.cidaas.com
• SCIM specification: IETF SCIM working group