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:

FeatureSAML SSOSCIM
AuthenticationYesNo
User CreationJIT (on first login)Automatic (immediate)
User DeprovisioningManualAutomatic
Role/Group SyncVia SAML attributesVia 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

  1. Enter a descriptive name for the token (e.g., "Okta SCIM Token")
  2. Click Generate Token
  3. Copy the token immediately - it will only be displayed once
  4. 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

  1. In Okta Admin Console, go to Applications > Applications
  2. Select your Cronitor application (or create a new SCIM app)
  3. Go to the General tab and ensure Provisioning=SCIM
  4. Go to the Provisioning tab
  5. Click Edit to configure the API Integration
  6. 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, and Push Groups
    • Authentication Mode: HTTP Header
  7. 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.

  1. Paste your SCIM token in the Authorization field (Okta automatically prefixes it with "BEARER")
  2. Click Test API Credentials to verify and click Save

Step 2: Configure User Provisioning

  1. 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

  1. Go to the Push Groups tab
  2. Click Push Groups and select Find groups by name
  3. Search for the Okta group you want to map (e.g., "Engineering Admins")
  4. 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)
  5. 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)

  1. Sign in to the Microsoft Entra admin center as a Cloud Application Administrator or higher
  2. Navigate to Entra ID > Enterprise Applications
  3. Select your Cronitor application
  4. Select the Provisioning tab
  5. Set Provisioning Mode to Automatic
  6. Under Admin Credentials:
    • Tenant URL: https://cronitor.io/scim/v2
    • Secret Token: Your generated SCIM token from Cronitor
  7. Click Test Connection to verify Microsoft Entra ID can connect to Cronitor
  8. Enter a Notification Email for provisioning error alerts
  9. Click Save
  10. Under Mappings, select Provision Microsoft Entra ID Users to review attribute mappings. The key matching attribute is userName.
  11. Set Provisioning Status to On
  12. 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:

EndpointMethodsDescription
/scim/v2/ServiceProviderConfigGETSCIM service provider configuration
/scim/v2/SchemasGETSupported SCIM schemas
/scim/v2/ResourceTypesGETSupported resource types
/scim/v2/UsersGET, POSTList and create users
/scim/v2/Users/{id}GET, PUT, PATCH, DELETEManage individual users
/scim/v2/GroupsGETList groups (Cronitor roles)
/scim/v2/Groups/{id}GET, PATCHManage group membership

User Attributes

Supported User Attributes

SCIM AttributeCronitor FieldRequired
userNameEmail addressYes
name.givenNameFirst nameYes
name.familyNameLast nameYes
activeAccount statusNo (default: true)
externalIdIdP user identifierNo

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 NameCronitor RolePermissions
adminAdministratorFull access, team management
userUserCreate and manage monitors
readonlyRead-onlyView-only access

How Group Sync Works

  1. Your IdP calls GET /scim/v2/Groups to discover available groups in Cronitor
  2. In your IdP's SCIM app settings, you map your IdP groups to Cronitor's SCIM groups
  3. 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

  1. Navigate to Team Settings
  2. Click Configure SSO
  3. Find the Default account role setting under JIT user provisioning
  4. Select the desired role: Read-only, User, or Admin
  5. 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

ScenarioRole Assigned
New user created via SCIM without group membershipDefault Role
New user created via SAML JIT provisioning without role attributeDefault Role
User removed from a SCIM group (e.g., removed from admin)Default Role

Best Practices

  • Set the Default Role to Read-only for 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 User and Read-only as 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:

  1. Generate a new token in Cronitor
  2. Update your identity provider with the new token
  3. Verify provisioning works with the new token
  4. 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

IssueSolution
401 UnauthorizedVerify your SCIM token is correct and active
404 Not FoundCheck the SCIM endpoint URL is correct
User not createdEnsure required attributes (userName, givenName, familyName) are mapped
Role not assignedVerify 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

PracticeDescription
Use descriptive token namesHelps identify which IdP uses each token
Rotate tokens periodicallyRecommended every 6-12 months
Monitor last used timestampsIdentify unused tokens for cleanup
Use separate tokens per IdPEasier revocation if needed
Test in staging firstVerify configuration before production rollout
Previous
SAML SSO