SCIM 2.0 – provisioning identities

As the number of applications used in modern organizations continues to grow, IT admins are tasked with access management at scale. Standards such as SAML or Open ID Connect allow admins to quickly set up single sign-on (SSO), but access also requires users to be provisioned into the app. To many admins, provisioning means manually creating every user account or uploading CSV files each week, but these processes are time consuming, expensive, and error prone. Solutions such as SAML just-in-time (JIT) have been adopted to automate provisioning, but enterprises also need a solution to deprovision users when they leave the organization or no longer require access to certain apps based on role change. This article will talk about the System for Cross-domain Identity Management (SCIM) which an open standard for identity management across applications.

Why was SCIM 2.0 developed?

To help automate provisioning and deprovisioning, applications expose proprietary user and group APIs. However, anyone who’s tried to manage users in more than one application will tell you that every application tries to perform the same simple actions, such as creating or updating users, adding users to groups, or deprovisioning users. Yet, all these simple actions are implemented just a little bit differently, using different endpoint paths, different methods to specify user information, and a different schema to represent each element of information.

To address these challenges, the SCIM specification provides a common user schema to help users move into, out of, and around applications. SCIM is becoming the de-facto standard for provisioning and, when used in conjunction with SSO standards like SAML or OpenID Connect, provides administrators an end-to-end standards-based solution for access management.

SCIM is a standardized definition of two endpoints – a /Users endpoint and a /Groups endpoint. Using common REST verbs to create, update, and delete objects, and a pre-defined schema for common attributes like group name, username, first name, last name and email, applications that offer a SCIM 2.0 REST APIs can reduce or eliminate the pain of working with a proprietary user management API. For example, any compliant SCIM client knows how to make an HTTP POST of a JSON object to the /Users endpoint to create a new user entry. This means that, instead of every application creating a slightly different API that does the same basic thing but requires proprietary code to call, applications can conform to the SCIM standard and instantly take advantage of pre-existing clients, tools and code.

OmniDefend and SCIM 2.0

OmniDefend integrates with SCIM both as a service provider (SP) and as an identity provider (IdP). As a service provider, 3rd party tools can be used to get, add, modify and delete user information in OmniDefend. Using some OmniDefend specific extensions, these tools can even get OmniDefend specific information about the user that is not defined in the SCIM 2.0 schema.

As an identity provider, OmniDefend uses SCIM 2.0 to provision and manage user access into 3rd party applications. For example, when OmniDefend is used with Salesforce, not only can SSO be configured via SAML or OpenId, but now when the admin uses the OmniDefend settings pages to provision user access to Salesforce, the user will be automatically created in Salesforce if required. In addition, de-provisioning of a user from OmniDefend can remove the user account from Salesforce so that you do not have user accounts in Salesforce which are not managed by OmniDefend.

Using the power of OmniDefend and SCIM 2.0 can greatly reduce the IT burden of provisioning and de-provisioning accounts when users join, leave or move roles in a large organization. Please note that this article may reference certain OmniDefend features which will be available in future releases of the product. You can request more information about OmniDefend and SCIM 2.0 by filling out the form here.