Skip to main content

SCIM 2.0

Description

The SCIM 2.0 connector uses the System for Cross-domain Identity Management (SCIM 2.0) standard REST API (RFC 7642–7644) to discover user accounts and groups from any SCIM-compliant identity provider. Authentication uses a Bearer token supplied in the Authorization header — this may be a static API key or an OAuth 2.0 access token depending on the provider. Pagination follows the SCIM 2.0 specification: startIndex, totalResults, and itemsPerPage response fields are used to walk through large result sets in pages of 100.

System Type Classification

FieldValue
System TypeDirectory Service
Default Scan Priority10 (scanned first)

Version Support

OrbisID EditionSupported
CommunityNo
ProYes
EnterpriseYes

Supported Protocol

ProtocolPortNotes
SCIM 2.0 REST API (HTTPS)443 TCPBearer token authentication

What OrbisID Discovers

DataSource
User accountsGET {baseUrl}/Users (all users, paginated)
User status (active/inactive)active field on each SCIM User resource
Display namedisplayName, name.formatted, or name.givenName + name.familyName
Primary emailFirst primary: true entry in the emails array
External IDexternalId field — links to source HR/IdM system if present
GroupsGET {baseUrl}/Groups (all groups, paginated)
Group membershipsmembers array on each SCIM Group resource
Privileged groupsGroups whose name contains admin, privilege, superuser, or root

Connection Requirements

Bearer Token

OrbisID authenticates to the SCIM provider using a Bearer token. How you obtain the token depends on the provider:

Provider patternHow to obtain the token
Static API keyGenerated once in the IdP admin console and stored permanently
OAuth 2.0 access tokenObtained via client credentials grant; must be refreshed before expiry
info

OrbisID stores the token in the encrypted credential and presents it on every scan request. If your provider issues short-lived OAuth tokens, generate a long-lived token or a service account API key instead, and refresh the credential in OrbisID before it expires.

Minimum permissions required on the SCIM service account / token:

  • Read Users — list all user resources at /Users
  • Read Groups — list all group resources at /Groups

Credential Mapping

OrbisID FieldSCIM Value
credential.passwordBearer token (OAuth access token or static API key)
credential.username(Optional) Leave blank or use a reference label
system.hostnameFull SCIM 2.0 base URL (e.g., https://idp.example.com/scim/v2)
note

The Hostname field must contain the full SCIM base URL including the scheme (https://) and any path prefix. OrbisID appends /Users and /Groups to this value to construct the endpoint URLs.

System Attributes

The following optional attributes can be set on the target system record to adjust scanner behaviour:

Attribute keyTypeDefaultDescription
scimUsernameAttributeStringuserNameCustom SCIM attribute to use as the OrbisID account name. Leave unset to use the standard userName field.
scimDiscoverGroupsBooleantrueSet to false to skip group discovery. Useful when the SCIM provider does not implement the /Groups endpoint.

Network Requirements

The OrbisID server (or On-Premise Agent) must have outbound HTTPS access on port 443 to the SCIM provider's base URL.

Configuration Steps

  1. Obtain a Bearer token or API key from your SCIM identity provider with read access to users and groups
  2. Create a Credential in OrbisID:
    • Username: (optional, e.g., scim-service-account for reference)
    • Password: The Bearer token or API key value
  3. Navigate to Systems → Add System
  4. Fill in the fields:
FieldValue
NameDescriptive name (e.g., SCIM – idp.example.com)
HostnameFull SCIM base URL (e.g., https://idp.example.com/scim/v2)
OS TypeSCIM 2.0
System TypeDirectory Service
CredentialThe Bearer token credential
  1. (Optional) Add system attributes for advanced configuration:
    • Set scimUsernameAttribute if your provider uses a non-standard attribute for account names
    • Set scimDiscoverGroups to false if group discovery is not needed or unsupported
  2. Click Test Connection — OrbisID issues a GET /Users?count=1&startIndex=1 probe and verifies that the response contains the SCIM schemas field
  3. Click Save

Common SCIM Provider Examples

The SCIM 2.0 connector works with any RFC-compliant SCIM provider. The following examples show the typical base URL pattern for common providers:

ProviderTypical SCIM Base URL pattern
Microsoft Entra ID (Azure AD)https://graph.microsoft.com/v1.0/... (use the Azure AD connector instead)
Oktahttps://<domain>.okta.com/scim/v2
OneLoginhttps://api.onelogin.com/scim/v2
JumpCloudhttps://scim.jumpcloud.com/1/
Custom IdPProvider-specific — consult your IdP documentation
tip

If OrbisID has a native connector for your provider (e.g., Okta, Ping Identity), prefer using that connector over SCIM 2.0 — native connectors retrieve more data and use provider-specific authentication flows.

Troubleshooting

SymptomLikely CauseResolution
SCIM authentication failed – check the Bearer tokenInvalid or expired Bearer tokenRegenerate or refresh the Bearer token in your IdP and update the OrbisID credential
SCIM access denied – the Bearer token lacks required read permissionsToken does not have read access to /Users or /GroupsVerify that the service account or token scope includes read access to users and groups
SCIM API error 404Incorrect base URLConfirm the SCIM base URL; check whether the provider uses /scim/v2, /v2, or another path prefix
Empty response from SCIM /Users endpointProvider returned an empty bodyCheck that the base URL is correct and that the endpoint returns a valid SCIM ListResponse
No groups discoveredProvider does not implement /GroupsSet scimDiscoverGroups to false in system attributes to suppress group discovery errors
Accounts show no display nameProvider does not populate displayName or name fieldsOrbisID falls back to userName or email; no action required
Connection test passes but scan returns 0 usersToken has permission to probe but not to listConfirm the token scope includes full user listing, not just a count endpoint