Introduction
Consider a Fortune 500 company, like a bank with 40,000 employees. A financial analyst at this company will use many SaaS tools to do their job, like Slack, Google Suite for Work, Zoom, Tableau, Workday, and more. In fact, enterprise organizations rely on an average of 211 apps each to run their businesses.
So, the bank’s central IT team might be responsible for managing 200+ SaaS apps, and our financial analyst may need access to a quarter of them. Naturally, for an employee to use all of those apps, accounts for each one would need to be provisioned first.
Fortunately, our bank’s IT team is smart. They utilize Okta Workforce Identity Cloud to maintain a directory of all their employees and enable easy account creation and access to those SaaS apps using Single Sign-On. That means they don’t have to manually provision SaaS apps every time a new employee joins the company or an existing employee needs access.
But what about other events in an employee’s time with the company, such as when they change their role, change their name or pronouns, or eventually leave the company? How many times might those events happen over 40,000 employees? And how might each of those changes be reflected in the SaaS apps that they use?
User Lifecycle Management Using SCIM
Fortunately, if a SaaS app used at the company relies on a workforce provisioning engine that utilizes SCIM (System for Cross Identity Management, a standard for automating the exchange of user identity information between identity domains), that app can synchronize its user list to the central employee directory and react to changes that happen in the directory.
For the bank’s central IT team, this means they can make updates to users once in their central employee directory and have those changes reflected in all of the SaaS apps an employee uses, reducing administrative overhead and toil.
The power of this “live” connection that SCIM provides becomes critical when an employee leaves the company. Once central IT deletes this employee from their central directory, any user accounts they had with those SCIM-powered SaaS apps will be deactivated within seconds, eliminating the chance of unauthorized access through “zombie accounts” and maintaining compliance with data privacy regulations, like GDPR.
Timely deprovisioning of former employees can have cost savings as well. When an employee leaves, the central IT team can quickly release the employee’s SaaS licenses and accurately reflect the reduced spend to the respective vendors.
So, you can imagine that the bank’s central IT team would want any new SaaS app it evaluates to leverage SCIM due to its many benefits:
- Saves a lot of manual labor
- Improves their security posture
- Saves their company money
How Does SCIM Provisioning Work?
SCIM works by providing a defined schema of identity data that represents users and groups, along with a REST API that supports JSON and XML for CRUD operations on those user and group resources.
Behind the scenes, SCIM is broken down into a few core components:
- SCIM Service Provider
- This service hosts the identity data and responds to SCIM API requests. It’s also commonly called a SCIM server.
- Examples: Cloud applications, identity providers (e.g., Okta)
- SCIM Client
- The SCIM Client initiates SCIM requests to interact with a SCIM server to perform operations that manage identities.
- Examples: Identity management systems, HR systems
- SCIM Schema
- The SCIM schema defines the structure of identity data.
- Core schemas: User, Group, EnterpriseUser (defined in RFC7643)
The SCIM core components then use an HTTP-based REST API that supports JSON and XML data formats, although JSON is more common. The REST API uses standard HTTP methods like GET, POST, PUT, PATCH, and DELETE to support CRUD operations.
SCIM supports a number of key operations, such as:
- User Provisioning
- The ”SCIM Client” sends a POST request to create a new user, and the ”SCIM Provider” creates the user and returns a unique identifier (ID).
- User Retrieval
- The ”SCIM Client” sends a GET request with the user ID or search criteria, and the ”SCIM Provider” returns user data that matches the request, provided the user exists.
- User Update
- The ”SCIM Client” sends a PUT or PATCH request with the updated user data, and the ”SCIM Provider” applies changes and confirms the update.
- User Deprovisioning
- The ”SCIM Client” sends a DELETE request, and the ”SCIM Provider” removes or deactivates the user account.
On top of this core functionality, SCIM also provides useful features such as:
- Bulk Operations
- Where batch processing can be applied for multiple SCIM operations in a single request
- Filtering and Searching
- Allows complex queries to find specific users or groups by using a standardized filter syntax
For each request, the SCIM REST API will return with the appropriate HTTP status to indicate success or failure along with detailed error messages for troubleshooting. SCIM typically uses OAuth 2.0 for authorization and supports HTTPS for secure data transmission.
SCIM is also extensible, which means that organizations can extend the standard SCIM schemas to accommodate their specific needs. For example, if an organization wants to include additional information about employees not covered by the standard SCIM schemas, then they can store additional information such as ”department” or ”manager” in their user profiles.
SCIM vs SAML
Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s most commonly used to enable Single Sign-On (SSO) across different web applications and services.
SCIM and SAML are both protocols for identity and access management (IAM). However, they serve different purposes.
SCIM is used for user provisioning and management across different systems and applications, ensuring that identity data is consistent across. SAML, on the other hand, is used to access multiple applications with a single set of credentials.
In summary, SCIM is for user management, while SAML is for user authentication.
SCIM vs. SSO
Single Sign-On (SSO) is an authentication method that allows users to sign in to multiple applications with a single set of credentials.
Although SCIM and SSO are related, SCIM is a protocol used for provisioning appropriate roles and groups to users, whereas SSO authenticates those users into multiple accounts with a single set of login credentials.
Inbound SCIM with Auth0
If you’ve been reading about SCIM online, you’ve probably found identity providers like Okta Workforce Identity Cloud and Microsoft Entra ID support SCIM in different ways, and that building for each of them can become a substantive effort. We’d advise that you learn about the identity providers your customers use and tailor your SCIM solution to meet the majority of your customers. However, If you think you will need to integrate your development with more than one identity provider, don't despair: there are solutions that allow you to easily connect to multiple identity providers at once.
In fact, that's one of the things we do at Auth0. Our Inbound SCIM solution allows you to integrate with Okta Workforce Identity Cloud, Microsoft Entra ID, and other identity providers via both SAML and OpenID Connect, manage attribute mappings on a per connection basis, and more.
Conclusion
SCIM is a powerful way to automate user lifecycles and maintain user accounts across platforms that can save companies time, money, and increase their security. Learn more about SCIM by exploring the Auth0 docs.