An Implementer’s Overview of Managing Cloud Identity with SCIM

System for Cross-domain Identity Management (SCIM) allows an enterprise to manage users across multiple cloud applications using a single interface. It might be helpful to think of it in terms of its original and more memorable acronym, Simple Cloud Identity Management.

You ended up with this poor configuration accidentally. Where to now?

The need for a standard like SCIM is easy to understand. With the proliferation of cloud based applications for business use, companies face an expanding number of admin consoles for each application. This is fine if your enterprise has one or two cloud apps. But as the number grows, the situation quickly becomes unmanageable. Admins find themselves having to go from cloud app to cloud app managing users, which would be tedious and repetitive even if the cloud apps all had the same UI for their management consoles. Given that cloud apps have wildly different interfaces, it is also confusing and frustrating.

The benefits of having a central location to manage users across applications become obvious as an enterprise begins to use more than a handful of applications for more than a small number of users.

What does an enterprise which uses too many cloud apps do to solve the problem? Add another cloud app, of course!  But this time the app addresses the problem of managing users across applications.

Sweet SCIM relief.

This is where a SCIM Client comes into play.  A cloud-based SCIM Client acts as a clearinghouse of SCIM integrations.  Instead of managing users in a variety of web interfaces in each cloud app used by the enterprise, a SCIM Client provides a single interface to manage users across compliant applications, referred to as Service Providers in the specification.  So if an employee joins an enterprise they can be provisioned to multiple applications from a single interface.  And when they leave they can be removed from all applications at once.

Implementing SCIM at Lucidchart

At Lucidchart, we currently have integrations for two SCIM providers: Okta and OneLogin. We prioritized these providers because the many of our customers using Single Sign On (SSO) were already doing so through Okta and OneLogin, making them a natural choice for our first release.

There are a few interesting things to note here.  The first has to do with security, which is an important thing to consider when delegating provisioning functionality to a third party.

The SCIM Client authenticates to the Service Provider and identifies which enterprise it is acting on behalf of using a bearer token.

How a bearer token is obtained and used needs to be understood in order to make judgements about how to best implement SCIM securely:

1. An enterprise user with admin priviledges logs in to Lucidchart, enables SCIM, and requests a bearer token.
2. Lucidchart provides this in plain text over HTTPS.
3. The admin then enters this bearer token into the Lucidchart app provided by their SCIM Client. (The bearer token is in plain text during that copy and paste operation, so don’t go pasting it into strange places.)
4. Once a bearer token has been issued, Lucidchart will trust anyone who shows up with it to do SCIM-related tasks.

There is no reason for the enterprise to keep the bearer token after uploading it to the SCIM Client.  If it’s lost or invalidated, a new one can be generated in the future.

Security

How a bearer token gets from a service provider to a SCIM client

Given that the SCIM Client has to be able to send the bearer token to the Service Provider in plain text over TLS, it is necessarily present on the SCIM Client’s systems in plain text at some point in each session.  There are more secure authentication schemes out there, but they are more complex and the industry seems to have settled on bearer tokens as good enough as long as they are sent over TLS.  But mistakes can be made, and if the bearer token gets out, the Service Provider can’t differentiate between legitimate requests and illegitimate ones.

Because of this, we make sure that the bearer token is only used to authenticate SCIM requests, and we don’t allow any destruction of documents or reading of customer documents based on those requests.  So if there is an attack where your bearer token is somehow exposed, the damage an attacker can do is limited. The bearer token is only used for SCIM endpoints and no other Lucidchart functionality.

Extensibility

Another consideration we had when implementing SCIM is that Lucidchart is available as a read-only application to all members of an enterprise, while paid users have editing privileges. Because of this we had to extend the SCIM schema to add a custom field and a corresponding field to our SCIM Client apps.  The custom field is labelled “Can Edit.”  We wanted terminology that was succinct and wouldn’t discourage anyone from enabling the option for users that need access to the full features of the product. This requires educating our customers to provision all of their employees with Lucidchart accounts and then enabling “Can Edit” for those that are going to be creating documents.

Thoughts on SCIM Endpoint Implementation

Beyond issuing bearer tokens and setting up an app with the SCIM Clients we wanted to integrate with, we had to implement a series of SCIM endpoints as defined by the spec and the SCIM clients. Note that not all endpoints get used by all SCIM Clients, so we didn’t implement all of the endpoints. For instance, neither provider we worked with has implemented the group endpoints yet.

One relatively easy part of implementing SCIM is that the API makes heavy use of JSON and has well defined base schemas, which can be extended as needed.  This greatly simplified the development process as we knew what to expect in the various calls and the data was easily readable.

The endpoints that we did implement are pretty straightforward, though we did have to pay attention to a few details. For instance, the POST command creates a new user.  But you’ll want to do some basic checking to make sure you aren’t overwriting an existing user.

The GET endpoint returns information about a user or is used to query for multiple users that match a pattern.  Because this can potentially return a large number of results, you’ll need to implement paging for responses.

The PUT endpoint changes or adds information associated with an existing user.   The primary concern here is making sure that the changes are made to the account without making it inaccessible in some way.  For instance, names and therefore email addresses can and do change. If you are using email as a unique identifier you need to handle this change carefully.

Summing Up SCIM

Of course, the fact that there is a standard doesn’t imply that all SCIM providers have implemented it in the same way.  We’ve run into quirks and differences between the two providers and expect to run into more as we expand our catalogue of SCIM providers in the future.  Luckily, the teams at Okta and OneLogin have been a pleasure to work with. We at Lucidchart are excited to be offering this powerful enterprise tool to customers.