The following provides documentation for deprovisioning using Azure and Inkling SCIM APIs. The workflow is based on Azure’s SAML authentication and SCIM Provisioning support. Azure provides support for user provisioning and deprovisioning using SCIM APIs as described here SCIM provisioning.

• User Authentication and Provisioning is setup in Azure under Single Sign On and that workflow is covered under SSO setup page
• User Provisioning via SCIM API is not yet fully supported by Echo360
• User Deprovisioning is supported now and the setup is in Azure under Provisioning as described on this page

User Deprovisioning via Azure using Inkling SCIM APIs

Getting ready

To create a new Inkling – Azure User deprovisioning integration, you will need the following:

• An Azure account with admin privileges.
• Inkling Tenant URL - Inkling provides this. Typically the link is

  https://enterprise-api.inkling.com/v2/scim?aadOptscim062020

• Customer Inkling Test Org API Secret Token - Inkling provides this.
  

  For a customer already in production, provisioning on a test org first is recommended to ensure everything is working before affecting end-user access.

• Customer Inkling Production Org API Secret Token - Inkling provides this.
• In addition, the customer’s Azure administrator should join the call. That resource should be familiar with Microsoft's provisioning information.

Setup for Provisioning / Deprovisioning

1. Log into Azure with an account with admin access rights to create and set up new applications.
2. You can skip this step if you already have an Inkling application from the early setup for SAML authentication. If not, select Create your own application and enter Inkling under What's the name of your app? Choose Integrate any other application you don't find in the gallery (Non-gallery).
3. Under Main Page, go to Manage > Enterprise Applications and search for and select the Inkling application created previously.
4. Select Provisioning from the left-side menu.
   
5. Within the left menu, select Manage > Provisioning. On the Provisioning mode page you will enter the Target URL and Secret Token from above.
   

   Remember to enter the correct Token depending on whether you are setting up for Test or Prod org.

6. Once complete, click Test Connection.
7. On the same screen, under Mappings, select Provision Microsoft Entra ID Groups and set Enabled to No.
   

   If you do not see Mappings, Save again. It can take a while to save so if you have updated and screen still shows Yes for Provision Microsoft Entra ID Groups, move on to next step and check back after Step 8.

8. Select Provision Microsoft Entra ID Users to update the mapping as follows:
   
   • Enable = Yes
   • Target Objects - You must check all three options: Create, Update, and Delete.
     

     Technically you are provisioning users as well as deprovisioning, and that is required. Checking the Delete option only will not work. However, since we do not support the association of attributes at this time in this provisioning process, a secondary provisioning process must be in place (SAML or file). When we talk about Azure SCIM integration, we officially only support deprovisioning (at this time). Technically, for a customer who does not use attributes and makes assignments to the Everyone group, provisioning via Azure SCIM support would work.

   • For Attribute Mapping, delete all Attributes except
     • userName
     • active
     • name.givenName
     • name.familyName
     • externalId
   • Review the default mappings, especially for userName and externalID.
9. After Mapping is complete, return to the previous page.
10. Under Settings, the Provisioning Status needs to be toggled On. If you do not see the Provisioning Status, please Save and refresh the page.
11. Save and exit.
    

    Deprovisioning via Azure will run at fixed intervals you determine within Azure.

Each Azure customer will have a unique setup. This example uses dynamic groups in AD.

The deprovisioning setup is still for Microsoft Entra ID Users. The dynamic group itself has a user role assignment. Users are added to the dynamic group via properties and then, since the dynamic group has a user role assignment in the Inkling application, any member of the group will be deprovisioned in Inkling.