System for Cross-domain Identity Management (SCIM) is an open standard that lets an external Identity Provider (IdP) create and maintain User accounts in another application automatically. Absorb LMS acts as a SCIM service provider, which means a supported IdP pushes User and Group data into your Portal and keeps it synchronized over time. This article describes the provisioning behavior common to every IdP, including the supported resources, the query capabilities, the recognized schemas, the authentication models, and the known limitations. 

For step-by-step configuration, see the Absorb SCIM in Okta and Absorb SCIM in Azure guides.

Supported Resources and Operations

Absorb exposes three SCIM resource families, all served under the base path scim/v2/. Each resource supports a defined set of operations, described in the table below.

Querying Users and Groups

When an IdP reads data from Absorb, it can shape the request using the standard SCIM query parameters. Absorb supports filtering, pagination, sorting, and attribute projection, each described below.

Filtering

Filters narrow a result set to records that match a condition. Absorb supports the standard comparison operators, and you can combine conditions using and, or, and not. The supported operators are listed in the table below.

Pagination

Large result sets are returned in pages. Use startIndex to set the first record returned and count to set the number of records per page. A single page returns a maximum of 1,000 records, so requests that exceed this limit are paged automatically.

Sorting

Use sortBy to choose the attribute to order by and sortOrder to set ascending or descending order. Sorting is available on top-level attributes and simple multi-valued attributes. See the Known Limitations section for one sorting constraint.

Attribute Projection

Attribute projection controls which fields a response includes. Use attributes to return only a specific set of fields, or excludedAttributes to return everything except a specific set. This keeps responses focused on the data the IdP needs.

Supported Schemas and Attributes

Absorb recognizes three SCIM schemas. Together they cover the standard User fields, the enterprise extension, and an Absorb extension for platform-specific data. The table below lists each schema and its most relevant attributes.

The customFields and userManagementSettings attributes let the Absorb extension carry Custom Fields and role assignments. For the full attribute-level mapping tables, including required fields and value formats, see the Absorb SCIM in Okta guide. 

For background on Custom Fields, see How To: Add a Custom Field.

Authentication

Absorb supports two authentication models, and the one you use depends on your IdP. Both models authorize SCIM requests against your Portal, and the required credentials are generated from the SCIM card on the Client Settings page after you enable the Enable SCIM toggle in Portal Settings.

OAuth 2.0 Authorization Code Flow

The OAuth 2.0 authorization code flow is used with Okta. Absorb issues a short access token that is valid for four hours, along with a refresh token that is valid for one year. The refresh token allows the IdP to obtain new access tokens without re-authenticating, so provisioning continues uninterrupted. You supply the Client ID and Client Secret from the SCIM card during setup.

Long-Lived Bearer Token

The long-lived bearer token model is used with Azure. A System Admin generates the token from the Absorb Admin Interface, and it is valid until 2037, which is the maximum expiration date the system currently supports. The token is displayed only at the time of generation, so store it securely. You can generate more than one token, and generating a new token does not invalidate existing tokens.

Known Limitations

The following constraints apply to SCIM provisioning across all IdPs. Behaviors specific to a single IdP, such as synchronization intervals, are documented in the individual setup guides.

• The /ServiceProviderConfig, /ResourceTypes, and Bulk endpoints are not implemented. Some IdPs probe /ServiceProviderConfig during setup and report a failure when it is not found.
• Group provisioning always creates Departments one level beneath the root Department, so the resulting structure is always flat.
• A DELETE request performs a soft delete rather than permanently removing the record, and setting active to false sets the User to Inactive. For the distinction between the two, see Deletion vs Inactivation for Courses, Curricula & Users.
• PATCH supports only the add, replace, and remove operations.
• The Schemas endpoint does not support filtering.
• Sorting cannot target a sub-property of a multi-valued attribute, such as an email type.
• A default Department must be set in the SCIM settings. User creation fails when no default Department is configured.

Identity Provider Setup Guides

The following articles provide step-by-step configuration for each supported IdP, along with the version history for the integration.

• Absorb SCIM in Okta
• Absorb SCIM in Azure
• SCIM Change Log