Overview
System for Cross-Domain Identity Management (SCIM) is an open standard protocol for automating the exchange of user identity information between identity domains and IT systems. SCIM ensures that employees added to the Human Capital Management (HCM) system automatically have accounts created in Azure Active Directory (Azure AD) or Windows Server Active Directory. User attributes and profiles are synchronised between the two systems, updating and removing users based on the user status or role change.
SCIM is a standardised definition of two endpoints: a /Users’ endpoint and a /Groups endpoint. It uses common REST verbs to create, update, and delete objects. It also uses a predefined schema for common attributes like group name, username, first name, last name, and email. Applications that offer a SCIM 2.0 REST API can reduce or eliminate the pain of working with proprietary user management APIs or products. For example, any SCIM-compliant client can make an HTTP POST of a JSON object to the /Users endpoint to create a new user entry. Instead of needing a slightly different API for the same basic actions, apps that conform to the SCIM standard can instantly take advantage of pre-existing clients, tools, and code.
Key Features & Functionality
Appian does not natively support SCIM, hence the custom application that this documentation refers to. The downloaded content contains two distinct Appian applications:
How can we set this up from Okta. When our Okta team tries to validate the credentials, Okta throws error that "No results for users returned". Can someone share the steps on how to set this up in Okta?
I encountered the same issue and think that there are some bugs in this application and some tricky bits with Okta itself.
First, I used Runscope/Blazemeter to run Okta's SCIM 2.0 test package, tweaking Appian until the first test passed - https://developer.okta.com/docs/guides/scim-provisioning-integration-test/main/
Then, set up Okta like this:
Okta then validated correctly. Still more work to go but the major issue I hit is the Appian app seems to be expecting query params purely as a string, but Appian WebAPIs send that information around as a dictionary so the parser needs work for any searching cases