Table of Contents
This implementation guide is designed to guide you through the setup and configuration of a SCIM implementation. A large portion of the configuration must be completed in the client’s IDP (identity provider).
Configuration
Step #1: Prepare the account
Your CS Representative must complete this step.
- Toggle on SCIM in the Integrations section of Client Setup.
- Save the page.
- Navigate to Roles and Permissions.
- When the page opens, open the Roles and Permissions section from the left panel.
- Click Add New Employee Role to create a new user role that can be used in testing the SCIM integration.
- Enter in a SCIM name identifier to reference the purpose of this user and then select Company Admin as the Legacy Employee Role.
- Click Create Role.
- The role permissions will then open. Grant the user access to Company/Account Admin permissions as well as toggling on the API Access permission at the top of the role and granting full access to the SCIM permission.
- Note: If a client has multiple accounts, and they need to create duplicate users in each, you will need to enable full access to the Allow to Merge Employees permission as well.
- Click Save in the top right corner of the page.
- Open the Employees section of Roles and Permissions.
- Click Add New Employee to create a test user and assign them the new SCIM user role.
- Make a copy of the SCIM Attribute Mappings file, which lists all of the default Paradox Attributes that are supported, and share it with the client.
- Note: Both the default and any additional custom attributes can be pulled from the schema APIs. This can be done by the client's technical resource or you.
Step #2: Determine the employee unique identifier
This step should be completed in collaboration with your CS Representative.
- Return to the Integrations section of Client Setup.
- In the SCIM subsection, select the Primary Attribute. This will default to the log in option set in the Data Privacy section of Client Setup, but it can be updated to one of the following:
- Employee ID
- SCIM External ID
- SCIM Username
- Phone Number
- Click the + Add IP Address button to add a whitelisted API.
- Repeat step #3 for all IP addresses that should be whitelisted. Otherwise, all IPs will be available to call Paradox's SCIM endpoints.
- Select the Max Bulk Operations limits. Options include:
- 5
- 10 (default)
- Save the page.
- Navigate to Roles and Permissions.
- Open the Roles and Permissions section from the left panel.
- Each user role in the CEM will need to have an External ID assigned to it. This will be the value that the client sends in the
roleattribute in order to assign the users to their appropriate user role. Hover over the first user role; click it's action menu, or ellipses; and then select Edit. - When the page opens, enter in the External ID assigned to the role.
- Save the page.
- Repeat steps #9-11 for each user role.
Step #3: Generate auth token
Your CS Representative must complete steps #1-5.
- Impersonate the new SCIM employee. You can do this by:
- Clicking your avatar.
- Clicking your name.
- Search for the SCIM user.
- Select their name from the list.
- Open their My Profile from the avatar menu.
- Click the Settings button in the top right corner of the profile.
- From the Account ID and API Secret section, click Generate API Secret.
- Copy the Account ID and the API Secret. These will be used as the
client_idandclient_secret, respectively, when generating the auth token.
Your team or your CS Representative can complete steps #6-8.
- Make an HTTP request to the Oauth2 endpoint using the appropriate base url, the
client_id, andclient_secretfrom the SCIM integration user.
| Method | POST |
|---|---|
| Endpoint | |
| Headers | |
| form-data | |
- Save the
access_tokenfrom the response body. The customer will need to add this to the SCIM integration in their IDP in order to successfully authorize their requests.
- The auth token should be shared with you as a private note using the Paradox PrivateBin tool.
Step #4: View the SCIM Resources
Customer users can review the below SCIM resources:
- Point the client to the SCIM 2.0 Implementations section of the SCIM Implementations documentation.
- The supported Paradox Implementation Client Handbook documentation (download and share as a PDF).
- Additional information can be found in this SCIM Protocol documentation on Paradox SCIM endpoints.
SCIM API testing
To test the SKIM authentication, follow the steps below.
- Collect the
client_idandsecret_keyfor the SCIM integration user you created in step #1 above. - Apply the values to the appropriate variables in the SCIM Postman collection, and post to the oauth2 endpoint.
Oauth2 endpoint
{
"info": {
"_postman_id": "b0cd3e06-1534-42f1-ba9a-a90a0007789b",
"name": "SCIM",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json",
"_exporter_id": "20564521"
},
"item": [
{
"name": "Users",
"item": [
{
"name": "[Sample] Get Users",
"protocolProfileBehavior": {
"disabledSystemHeaders": {
"host": true
}
},
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/scim+json"
}
],
"url": {
"raw": "{{host}}/scim/v2/Users",
"host": [
"{{host}}"- The
access_tokenin the response can now be used in theAuthorizationheader.
SCIM attribute mapping
View SCIM attribute mapping here.
| SCIM | Comment | |
| Core User | SCIM Attribute | |
| extenalId | Needs to be added to Core Schema | |
| userName | ||
| name.formatted | ||
| name.familyName | ||
| name.givenName | ||
| name.middleName | ||
| title | ||
| userType | ||
| preferredLanguage | ||
| locale | ||
| timezone | ||
| active | ||
| password | ||
| emails.type (work) | ||
| emails.value (work) | ||
| emails.type (home) | ||
| emails.value (home) | ||
| phoneNumbers.type (work) | ||
| phoneNumbers.value (work) | ||
| phoneNumbers.type (home) | ||
| phoneNumbers.value (home) | ||
| addresses.type (work) | ||
| addresses.streetAddress (work) | ||
| addresses.locality (work) | ||
| addresses.region (work) | ||
| addresses.postalCode (work) | ||
| addresses.country (work) | ||
| addresses.type (home) | ||
| addresses.streetAddress (home) | ||
| addresses.locality (home) | ||
| addresses.region (home) | ||
| addresses.postalCode (home) | ||
| addresses.country (home) | ||
| role | ||
| Enterprise User | ||
| employeeNumber | ||
| department | ||
| manager.value | ||
| manager.$ref | ||
| manager.displayName | ||
Troubleshooting
User attributes are not successfully updating, even though a 200 OK response is received.
Root cause: API credentials need to be associated with a role whose legacy role is Company Admin to make attribute updates.
Solution: Check the API User custom role and ensure that the legacy role is Company Admin.