Users & Security
SCIM Provisioning
SCIM (System for Cross-domain Identity Management) enables automatic user provisioning and deprovisioning from your identity provider. When configured, users added to your IdP will automatically get Cronitor accounts, and users removed will be deprovisioned.
Overview
SCIM complements SAML SSO by automating the user lifecycle:
| Feature | SAML SSO | SCIM |
|---|---|---|
| Authentication | Yes | No |
| User Creation | JIT (on first login) | Automatic (immediate) |
| User Deprovisioning | Manual | Automatic |
| Role/Group Sync | Via SAML attributes | Via SCIM Groups |
Configure SCIM in Cronitor
Step 1: Access SCIM Configuration
Log into Cronitor as an administrator, navigate to Team Settings, and click the "Configure SCIM" button.
Note: SCIM provisioning requires the Business plan.
Step 2: Generate a SCIM Token
- Enter a descriptive name for the token (e.g., "Okta SCIM Token")
- Click Generate Token
- Copy the token immediately - it will only be displayed once
- Store the token securely for use in your identity provider configuration
Step 3: Note Your SCIM Endpoint
Your SCIM endpoint URL is:
https://cronitor.io/scim/v2
Configure Your Identity Provider
Okta
Step 1: Configure SCIM Integration
- In Okta Admin Console, go to Applications > Applications
- Select your Cronitor application (or create a new SCIM app)
- Go to the General tab and ensure Provisioning=SCIM
- Go to the Provisioning tab
- Click Edit to configure the API Integration
- Enter:
- SCIM connector base URL:
https://cronitor.io/scim/v2 - Unique identifier field for users:
userName - Supported provisioning actions: Enable
Push New Users,Push Profile Updates, andPush Groups - Authentication Mode: HTTP Header
- SCIM connector base URL:
- Check Import Groups to allow Okta to discover Cronitor's role groups
Okta requires Import New Users to be enabled when enabling Import Groups. This is safe to enable—it only allows Okta to discover groups from Cronitor. Users will not be imported unless you explicitly trigger an import.
- Paste your SCIM token in the Authorization field (Okta automatically prefixes it with "BEARER")
- Click Test API Credentials to verify and click Save
Step 2: Configure User Provisioning
Under Provisioning > To App, click Edit and enable:
- Create Users
- Update User Attributes
- Deactivate Users
Leave Sync Password disabled since Cronitor uses SSO for authentication.
Step 3: Configure Group Push for Role Assignment
- Go to the Push Groups tab
- Click Push Groups and select Find groups by name
- Search for the Okta group you want to map (e.g., "Engineering Admins")
- When prompted to choose a target group, select the corresponding Cronitor group:
admin— Administrator role (full access)user— User role (create and manage monitors)readonly— Read-only role (view-only access)
- Repeat for each Okta group you want to map to a Cronitor role
When users are assigned to these Okta groups and provisioned to Cronitor, they will automatically receive the corresponding Cronitor role.
Azure AD (Entra ID)
- Sign in to the Microsoft Entra admin center as a Cloud Application Administrator or higher
- Navigate to Entra ID > Enterprise Applications
- Select your Cronitor application
- Select the Provisioning tab
- Set Provisioning Mode to Automatic
- Under Admin Credentials:
- Tenant URL:
https://cronitor.io/scim/v2 - Secret Token: Your generated SCIM token from Cronitor
- Tenant URL:
- Click Test Connection to verify Microsoft Entra ID can connect to Cronitor
- Enter a Notification Email for provisioning error alerts
- Click Save
- Under Mappings, select Provision Microsoft Entra ID Users to review attribute mappings. The key matching attribute is
userName. - Set Provisioning Status to On
- Click Save to start the initial synchronization
The initial sync takes longer than subsequent cycles, which occur approximately every 40 minutes. You can monitor progress in the Provisioning logs.
SCIM Endpoints
Cronitor implements the following SCIM 2.0 endpoints:
| Endpoint | Methods | Description |
|---|---|---|
/scim/v2/ServiceProviderConfig | GET | SCIM service provider configuration |
/scim/v2/Schemas | GET | Supported SCIM schemas |
/scim/v2/ResourceTypes | GET | Supported resource types |
/scim/v2/Users | GET, POST | List and create users |
/scim/v2/Users/{id} | GET, PUT, PATCH, DELETE | Manage individual users |
/scim/v2/Groups | GET | List groups (Cronitor roles) |
/scim/v2/Groups/{id} | GET, PATCH | Manage group membership |
User Attributes
Supported User Attributes
| SCIM Attribute | Cronitor Field | Required |
|---|---|---|
userName | Email address | Yes |
name.givenName | First name | Yes |
name.familyName | Last name | Yes |
active | Account status | No (default: true) |
externalId | IdP user identifier | No |
Example User Payload
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "user@example.com",
"name": {
"givenName": "John",
"familyName": "Doe"
},
"emails": [
{
"value": "user@example.com",
"primary": true
}
],
"active": true,
"externalId": "okta-user-12345"
}
Group/Role Mapping
Cronitor exposes SCIM groups that your identity provider discovers and uses for role assignment. Cronitor exposes three groups:
| SCIM Group Name | Cronitor Role | Permissions |
|---|---|---|
admin | Administrator | Full access, team management |
user | User | Create and manage monitors |
readonly | Read-only | View-only access |
How Group Sync Works
- Your IdP calls
GET /scim/v2/Groupsto discover available groups in Cronitor - In your IdP's SCIM app settings, you map your IdP groups to Cronitor's SCIM groups
- When users are synced, your IdP sends the Cronitor group name, and Cronitor assigns the corresponding role
Default Role
When a user is provisioned via SCIM without a group assignment, or when a user is removed from all groups, they are assigned the Default Role. This setting is shared with SAML JIT provisioning.
Configuring the Default Role
- Navigate to Team Settings
- Click Configure SSO
- Find the Default account role setting under JIT user provisioning
- Select the desired role:
Read-only,User, orAdmin - Click Save Configuration
The Default Role applies to both SCIM and SAML JIT provisioning. Changing this setting affects all newly provisioned users regardless of provisioning method.
When the Default Role is Used
| Scenario | Role Assigned |
|---|---|
| New user created via SCIM without group membership | Default Role |
| New user created via SAML JIT provisioning without role attribute | Default Role |
User removed from a SCIM group (e.g., removed from admin) | Default Role |
Best Practices
- Set the Default Role to
Read-onlyfor maximum security - users can be promoted to higher roles as needed - If your IdP consistently syncs group memberships, the Default Role primarily serves as a fallback
- Consider your team's workflow when choosing between
UserandRead-onlyas the default
Managing SCIM Tokens
Viewing Tokens
Navigate to SCIM Settings to view all active SCIM tokens, including:
- Token name
- Creation date
- Last used timestamp
Rotating Tokens
To rotate a SCIM token:
- Generate a new token in Cronitor
- Update your identity provider with the new token
- Verify provisioning works with the new token
- Delete the old token in Cronitor
Revoking Tokens
Click Remove next to any token to immediately revoke it. Any identity provider using that token will no longer be able to provision or deprovision users.
Troubleshooting
Common Issues
| Issue | Solution |
|---|---|
| 401 Unauthorized | Verify your SCIM token is correct and active |
| 404 Not Found | Check the SCIM endpoint URL is correct |
| User not created | Ensure required attributes (userName, givenName, familyName) are mapped |
| Role not assigned | Verify group membership is being pushed from your IdP |
Testing the Connection
You can test your SCIM configuration using curl:
curl -X GET "https://cronitor.io/scim/v2/ServiceProviderConfig" \
-H "Authorization: Bearer YOUR_SCIM_TOKEN"
A successful response indicates your token is valid.
Security Best Practices
| Practice | Description |
|---|---|
| Use descriptive token names | Helps identify which IdP uses each token |
| Rotate tokens periodically | Recommended every 6-12 months |
| Monitor last used timestamps | Identify unused tokens for cleanup |
| Use separate tokens per IdP | Easier revocation if needed |
| Test in staging first | Verify configuration before production rollout |