WhyLabs SCIM V2 Introduction

WhyLabs supports integration with automated user provisioning systems using the System for Cross-domain Identity Management (SCIM) protocol. This is a standard protocol that allows for simplified user provisioning and management in identity management systems. This section outlines the steps to use the SCIM V2 protocol with WhyLab's SCIM V2 service.

Introduction to SCIM V2

SCIM V2 is a RESTful protocol designed to simplify the management of user identities, attributes, and resources. It offers a standardized way to create, read, update, and delete user and group data within an identity provider.

References

1. SCIM (System for Cross-domain Identity Management) Specification:
   • RFC 7643: SCIM: Core Schema
   • RFC 7644: SCIM: Protocol

Typical Provisioning Flow with Automated Provisioners

Automated provisioners like Okta, SailPoint, and similar identity management systems enable organizations to automate the process of user provisioning, deprovisioning, and synchronization across various applications and services. When integrated with a SCIM V2 service, these provisioners facilitate efficient user lifecycle management. Here's a typical provisioning flow:

1. Integration setup:

   • Provisioner setup: Integrate the WhyLabs SCIM API (acting as a SCIM Service Provider) with the automated provisioner (acting as a SCIM Client). This involves configuring the provisioner to communicate with the WhyLabs SCIM V2 endpoints, typically using endpoint URLs, authentication credentials, and other necessary settings.

2. User creation:

   • Provisioner initiates: When a new user is created or onboarded within the automated provisioner (e.g., Okta or SailPoint), the provisioner generates a SCIM request to create the corresponding user in your SCIM V2 service. The request includes user details and attributes.
   • WhyLabs SCIM service processes: WhyLabs SCIM Service receives the SCIM request, validates it, and creates the user based on the provided attributes.

3. User updates:

   • Provisioner initiates: When a user's attributes are updated within the automated provisioner, such as a change in the user's email or department, the provisioner sends a SCIM update request to the SCIM V2 service.
   • WhyLabs SCIM service processes: WhyLabs SCIM Service processes the update request, modifying the corresponding user's attributes accordingly.

4. Group membership changes:

   • Provisioner initiates: If a user's group memberships change within the provisioner (user added to/removed from groups), the provisioner sends SCIM requests to update the group memberships.
   • WhyLabs SCIM service processes: WhyLabs SCIM Service receives these group membership update requests and adjusts the user's group memberships accordingly.

5. User deprovisioning:

   • Provisioner initiates: When a user is offboarded or deactivated in the provisioner, the provisioner generates a SCIM request to deactivate or delete the corresponding user in your WhyLabs SCIM Service.
   • WhyLabs SCIM service processes: WhyLabs SCIM Service processes the deprovisioning request, deactivating or deleting the user and updating their status.

6. Error handling and logging:

   • Both the automated provisioner and WhyLabs SCIM Service should have mechanisms to handle errors, retries, and logging. This ensures that provisioning operations are reliable and transparent.

7. Synchronization intervals:

   • The automated provisioner may periodically synchronize user and group data with the WhyLabs SCIM V2 service to ensure data consistency. This synchronization interval should be configured based on organizational needs.

The specific steps, configurations, and settings can vary depending on the automated provisioner being used.