SCIM Explained – How Does It Work in Practice?

What Is SCIM?

SCIM (System for Cross-Domain Identity Management) is a standardized specification for managing user identities across applications. It is widely adopted, especially in cloud-based environments, and simplifies integration with centralized Identity and Access Management (IAM) systems.

If you are seeking an IAM solution, you likely have a hybrid environment with both on-premises and cloud-based systems. Originally developed with cloud applications in mind, SCIM is a general protocol for data exchange and not limited to the cloud. The Garancy Suite, for example, supports shifting originally cloud-based deployments to on-premises and vice-versa – and SCIM works seamlessly in either scenario.

The main advantage of SCIM is that provisioning works with minimal configuration. Once a connection is established and authorized, the system can automatically provision users, groups, and other resources and manage their attributes and group memberships.

But what makes this automation possible? Let’s explore the smart design behind SCIM that enables this functionality – and examine why, in practice, configuration is not always as effortless as intended.

How Does SCIM Work? 

Applications managed via SCIM are called service providers. They expose a REST interface that implements the SCIM standard. When an IAM system such as Azure (Entra ID), Garancy, or Okta connects to a SCIM-enabled application, it acts as the client.

In SCIM, every entity offered by a service provider is called a resource. The standard defines the resource types User and Group, each with a set of attributes.

This setup covers many basic use cases: User accounts and groups can be created or deleted, attributes managed (e.g., password resets). Group memberships can be assigned through the members attribute in a group to control user rights.

This describes how SCIM 1.1 worked, but it is limited. For example, what if a service provider wants to add an alias attribute to users, or enable management of additional resources like entitlements, password policies, roles, or devices?

SCIM 1.1 clients cannot handle such custom attributes or resources automatically – they require manual configuration or custom support.

SCIM 2.0 – Dynamic Discovery and Schema Flexibility

SCIM 2.0 addresses these limitations by introducing service discovery endpoints to discover the capabilities of a service provider. One of them allows service providers to define their own resource types, and another to declare the attributes they support for each resource.

Different service providers define a wide range of resource types, such as Account, Authorization, Container, Department, Device, Entitlement, Organization, Password Policy, or Role.

Each resource type’s attributes are defined in three ways:

1. Common attributes and the schemas attribute – defined by SCIM and automatically added to all resources

2. Base attributes – defined in a base schema referenced by the resource type

3. Extension attributes – added via schema extensions

Common attributes and the schemas attribute are fixed by the SCIM standard and their properties cannot be changed. Each resource type references one base schema, which is available at a separate endpoint and can be shared by multiple resource types.

Base schemas can be extended by referencing additional schemas as extensions, which add extension attributes. This ensures that attributes from different schemas remain separate, even if they share the same name.

How Far Does SCIM Support Go?

While SCIM aims to enable fine-grained IAM across applications, real-world implementations often fall short. SCIM support in a service provider or IAM system does not guarantee specific features or compatibility.

The SCIM standard (RFC 7643 and RFC 7644) is intentionally open, allowing anything from limited, read-only access to a few resources, to full access to all attributes and settings – including comprehensive support for User and Group resources.

Unfortunately, RFC 7643 is imprecise in places and has many errata, leading to varying interpretations and implementations that hinder compatibility. Still, some common patterns have emerged. Learn more about this when we explain how to create a SCIM 2.0 server configuration by hand.

Typical SCIM Implementation Patterns

Almost all service providers implement the core User and Group resources using the standard core schemas, often with the Enterprise User schema extension. Group memberships are typically managed via the group’s members attribute, as the standard intends.

Schemas are customized: Unsupported attributes are removed and properties are adjusted, e.g. marking attributes as required or read-only. Additional attributes are usually added to User and Group resources via schema extensions, although a few service providers also add attributes to the core schemas.

A typical SCIM service provider (like Atlassian) supports the core User and Group resource types and about 40 attributes and sub-attributes. Larger providers, such as SAP Identity Directory Services (IdDS), offer more resource types and custom schema extensions, totaling over 250 attributes and sub-attributes.

Smart SCIM Connect in Garancy

Garancy’s new smart SCIM connector, available in version 26.1, takes full advantage of SCIM’s resource type and schema information to provide an automated set-up with the full flexibility the SCIM standard has to offer.

This works best when service providers supply accurate schema data – many do, allowing Garancy to manage all available attributes with minimal configuration. The connector handles different SCIM interpretations and tolerates minor Schema errors, which are common, partly due to errata in the schema definitions included in RFC 7643. Since RFCs are not updated, these errors must be corrected manually. The corrected core schemas can be downloaded in the SCIM 2.0 Schema Checker.

However, some service providers, including major ones, have significant schema issues that restrict automatic discovery. To deal with such issues, Garancy’s connector can dynamically correct provider responses and adjust requests, configurable via simple Velocity templates in a low-code manner. The SCIM 2.0 Schema Checker helps verify schema definitions and identify issues needing adjustments.