SCIM, which stands for System for Cross-domain Identity Management, is a specification for adding and removing users and groups using a standard protocol.
Now, as of version 1.36, FusionAuth can consume SCIM requests and act as a provisioning server in a SCIM client/server environment. If you are interested, you can learn more here.
But this post is not about FusionAuth support; rather it is about what SCIM is and why you might want to use it.
What does SCIM allow you to do?
At a high level, SCIM support allows you to provision and de-provision (add and remove) users and groups from your identity systems. When a new user is added to one system, that user’s details can spread to other systems with their own data stores.
An example would be when a new developer is added to an HR system, they can be added to other systems needed to do their job, such as a cloud computing provider, a source control system, and a tournament management system. of ping pong.
If a new customer is added to a SaaS application, SCIM can add them to the support ticket system and also to the accounting system.
As you can imagine, you would have to have multiple systems and users for it to be worth implementing SCIM. If you only have ten clients and bring in one a month, automation may not be your top priority. But there are many companies with a large number of employees and users, for whom SCIM makes sense.
Why would you use SCIM?
By implementing SCIM, you can integrate with a number of existing apps. As with any other standard, interoperability is a huge win with SCIM.
As mentioned above, SCIM is useful for large organizations, so being SCIM compliant can open up opportunities to sell to such large organizations.
With SCIM, you’re replicating data everywhere. This is an approach that contrasts with single sign-on and federation, where identity data is consolidated and users and applications rely on one source of truth to determine identity information, access levels, and more.
But when you have applications that want to manage their own user storage or that don’t support standards like OIDC (OpenID Connect) and SAML (Security Assertion Markup Language), you may need to replicate user data. Instead of configuring the app to rely on a single user data store, you can send the necessary identity information to the app. If those apps support SCIM, you can add, update, and delete users as needed.
You can also use SCIM to move parts of your identity from one information source to another system, possibly outside your organization. For example, if you subscribe to a SaaS application and have your data stored on an identity server, the identity server may use SCIM to send some of your information, such as your email address, to the SaaS application, while retaining other information. information, such as your date of birth.
Another common use case is when you are not necessarily provisioning the same resources on multiple systems, but simply provisioning them on a single SCIM server. If you have multiple SCIM clients that want to provision and query for resource data, this may make sense, especially if the clients are third-party products that already know how to “speak” SCIM.
When starting out with an identity system, you often need to provision users, and SCIM can help you do that. For CIAM (Customer Identity and Access Management) systems, self-registration may work in certain scenarios, but there may be applications for which user self-provisioning is not acceptable.
There are additional use cases described in the RFC.
Let’s dive into some of the main pieces of SCIM.
Client and Server
There are two players in the SCIM game: the client and the server. The client provides the user data to the server.
In the example above, when a new developer is added to one HR system, SCIM adds them to other systems as well. In this case, the human resources system is the client and the other systems are servers.
When you’re evaluating SCIM solutions, make sure you understand whether they implement SCIM as a client, server, or both. For example, FusionAuth currently only implements SCIM as a server, capable of receiving user and group data.
Users and Groups
Everything SCIM manages is a resource.
There are three basic resources:
EnterpriseUsers. SCIM can be extended to support other types of resources. These may be refinements of the basic resources to model particular types of users. If you are using SCIM to provision users at a university, you may have
Students as resources. They can also model other types of identity management concepts, such as
EnterpriseUsers are similar, with
EnterpriseUsers schema extension
Users. Therefore, for the rest of this post, I am going to focus on
Users have a defined set of attributes, many of which you might expect. These include
userType and more. Exactly what you would expect a user to have. You can also put a user in a group.
Users You can also have emails, phone numbers, addresses, and more. They may even have a list of x.509 certificates. Each user also has a password, which is write-only.
The required fields are few: the
userName Field is required. Also, a
id The field must be created and assigned by the server.
I’ll let you check the relevant section of the RFC to get the full list of attributes for this resource.
Groups, on the other hand, are much simpler. have a requirement
displayName and a list of members, as well as a
Schemas are a critical part of SCIM and control what attributes each type of resource has.
Groups The resources discussed above have their own standardized schema, but you can create your own or, as mentioned above, extend it.
Schemas support single value attributes like
userType with a variety of data types, as well as multi-valued attributes like phone numbers or emails.
There are up to two identifiers for each resource in SCIM.
The first is the
id, which is a required attribute and is a globally unique identifier managed by the SCIM server. It must be stable and always refer to the same resource.
externalId, on the other hand, is provided by the client. It is optional and allows provisioning process identifiers to be stored on the server.
For example, the human resources system discussed earlier might have an identifier for the developer. It could be stored in the cloud computing provider’s SCIM data store. That way, you could directly query in the cloud computing system for a given record based on human resource ID.
$ref The attribute is commonly used. This string is an HTTP addressable resource that points to additional information about this element, and is often used to convey relationships between resources in SCIM. For example, a user object may contain group membership information. That group information may contain a
$ref attribute pointing to the SCIM identifier of that group.
There are a number of supported operations. As expected, CRUDL supports every resource and the API is largely RESTful:
Createwhich uses HTTP
Readwhich uses HTTP
Updatewhich uses HTTP
Deletewhich uses HTTP
Listwhich uses HTTP
POSTmethod (under certain circumstances)
List The operation optionally supports filtering, so you can find all users with a username containing
danand sort, so you can sort the returned resources by their type. You can also specify certain attributes to return or exclude.
Update operation must support the
PUT method, but can optionally support
PATCH. In the first case, the request completely overwrites the resource. In the latter, the attributes contained in the request are merged into the resource.
There are also bulk operations, designed to apply any of the mutation operations (
Delete) on many resources at once.
The specification has more
MAYI know what
MUSTs, so look at the documentation and/or machine-readable configuration endpoints (described below) before you do any of these things.
A SCIM server defines a series of configuration endpoints, which can be used to inform and automatically configure clients. These include:
ServiceProviderConfigwhich specifies what optional features are implemented, including authentication schemes, bulk endpoints, query filtering, and patch support.
ResourceTypesdescribes the types of resources available from the SCIM server, such as
Usersas well as its schema ID.
Schemasdescribes the fields for each available resource type, including the data type and whether the field is mutable.
These configuration endpoints are JSON. This means that any SCIM client or other program can read these endpoints and determine if the required functions are present. This setting can also be useful in determining what resources or attributes for those resources are available.
So how do you actually use SCIM? First, determine if you are going to receive data or send it. That is, are you a SCIM server or a client? Then determine if you can use the basic schemas, if you can use a standardized extension, or if you need to extend one.
Then, if you are a client, start the integration by determining how to authenticate to the server. If it is a server, determine which authentication methods it will support.
If you are a client, map your user and group attributes to the schemes supported by the server. If it’s a server, map the schemes it will support to its internal storage of identity data.
Other things to consider:
- Will you be syncing data in batches, user by user, or on a scheduled basis?
- Is there a time frame for creating or deleting users?
- What are the performance characteristics of the client and server?
- How will you secure the connection between the client and the server? Authentication is built in, but do you need other measures, like a VPN, IP restrictions, or client certificates?
Here are some additional resources:
*** This is a syndicated Security Bloggers Network blog from FusionAuth blog written by The FusionAuth Blog. Read the original post at: https://fusionauth.io/blog/2022/06/27/what-is-scim