SCIM APIs: A Use Case to enhance your Central Identity Management (CIM) Process
Need a refresher on SCIM? Read our [Start Here] article!
What is User Provisioning?
Let's start with a reminder;
User Provisioning is a process by which an individual is granted access to the Anaplan platform and assigned the model role that allows them to interact with the information that they are authorized to use.
We usually address User Provisioning in two ways:
- Manual: a Workspace Administrator (WSA) will assign User Roles and Selective Access within each model
- [Edited Nov 15th 2021] Automated via bulk APIs: The first step of adding a user is done via Import Actions from sources like files and integration with 3rd party systems. The second step of assigning Roles and Selective Access can be either manual (by a WSA) or automated via bulk import.
Note: a User Access model on Anaplan can also be used as a User data source.
Usually, in small and medium structures, this is not a real issue: when this process has been addressed, either via imports or a dedicated model-to-model functionality, things will run smoothly.
This article is more orientated towards organizations with needs for more segregation of duty when it comes to Security and User Provisioning.
Where CIM comes into play
To be fair, there are a few drawbacks to the methods described earlier.
- Deactivating a user from a model is quite straightforward but removing access from a workspace is not.
- The user performing those imports and maintaining User access needs to be WSA.
This is putting the burden of Security on a Model Builder who should be focusing on higher-value tasks.
The CIM (for Centralized Identity Management) console addresses those 2 points.
For the first point, deactivating a user from a workspace is quite easy.
By simply unchecking the boxes, the user is automatically stripped out of a workspace: there is no risk that this user will be added to any new model in the workspace.
On the second point, CIM will be accessible by the Security Admin, who does not require access to any Anaplan models through the UI nor requires to be a WSA. That will help to improve the segregation of duty.
Where SCIM comes into play
From what has been explained above, we can notice that some actions still require access to the Anaplan UI and manual manipulation.
What about the automation of those actions and the integration with other IDMS providers?
To address those, Anaplan releases the support of SCIM APIs.
SCIM stands for Systems for Cross-Identity Management.
It’s actually a norm that has been thought to address user provisioning for cloud solutions.
Using a standard will help the integration with other IDMS providers (like Okta or Azure AD).
By creating a connection between those 2 systems, people in charge of user provisioning won't need to go to the Anaplan UI to create users and manage them.
Creating an Application in Okta
Below, we show how to use Okta to add new users. You’ll notice that there is no need to access Anaplan to do so.
Create an Okta application
Choose SWA as application type
In the next screen, add a meaningful name to the application and make sure that you’ve pasted the right URL address.
Validate the app creation via clicking on Finish.
Once the application is created, go to the General tab and on the left of the “App Settings” title, click on Edit in order to make the tab editable.
Choose SCIM as Provisioning.
This will add another tab “Provisioning”. Select it and render the “Integration” part editable.
Make sure you fill in the different information thoroughly:
- “SCIM connector base URL”: it’s the same Anaplan SCIM URL you’ve used earlier
- “Unique identifier field for users”: it’s the tag that will make each user distinct from each other. Here it is userName (for which we use the email).
- Supported provisioning actions:
“Push New Users”
“Push Profile Updates” - For the Basic Auth part, use the credentials supposed to be used for SCIM.
If everything is set up correctly, then testing the connector should give you this screen.
You can now go to the Assignments tab and start provisioning users!
Note: you need to be a User Admin to do so, make sure you have this role assigned – if you do not know how to be assigned this role, check this page or contact your Anaplan Tenant Admin.
In the screenshots above, we’ve created an application that acts as the bridge between Anaplan and Okta using SCIM.
From now on, Okta admin can simply assign or unassign users and they’ll be enabled or disabled in Anaplan automatically: no need for them to go in the Anaplan UI (like the Users tab) to do so.
Would your current users' provisioning process be affected by SCIM? Should you use the new SCIM APIs?
As described earlier, if there is no need to integrate with tools like Okta, the most probable answer to the first question will be no. Nevertheless, for the second one, we think that even though no changes will be required for some time, users' creation and deactivation can be smoother.
We are enhancing the experience to answer frequent requests from Security departments, working with Okta or other Identity Providers for reporting user status (e.g. snapshots of all disabled users), or ensuring that disabled users can’t access Anaplan anymore.
That’s why leveraging the SCIM APIs for users’ creation and deactivation today can be a good option.
Even if your sources are not-SCIM compliant; you can simply shape the data in the right format and you can manage Users.
As shown below, on the right, we can imagine disconnecting the users’ creation and deactivation process from the selective access settings process.
It will then improve the auditability of the users’ management process and strip out the burden of maintaining users' access to Anaplan for WSAs.
They will then only focus on in-model Selective Access configurations.
In our next part, we will show a simple Anaplan model used with a script leveraging SCIM APIs to create the user and assign it to the chosen workspaces.
You can use another application than an Anaplan model (it might be a database or a custom web-based application) but the concept will be similar.
Using SCIM APIs with a non-SCIM source and a custom script
First, you need to build a model allowing Users Admins to enter the basic information required for user creation.
SCIM APIs leverage this basic information to function properly.
As shown below, our example only asks for:
- Name: it will be considered as the “userName” for SCIM => the user’s email
- External_id: typically, it will be the code designating the user and coming from other sources.
- GivenName: would usually be the first name.
- FamilyName
- Workspace: list of workspaces our new user will be assigned to.
- Active
Note: In our example, we used a web service that we can activate by simply clicking on the link, in the last line.
Basically, what the web service does is get the data from the model and format it in the following way:
After the web service sent the formatted information, we can check in the administration console and validate that our new user has been created in the Anaplan system.
In summary, we’ve been able to create a simple application, using an Anaplan model as a source and create users in the admin console.
Again, this is an example and you could use any other source type with custom integration.
How are you leveraging the SCIM APIs? Let us know in the comments below.
Contributing author Christophe Keomanivong.