Test a SCIM server or SCIM connector


Okta provides a connector testing utility to test your SCIMSystem for Cross-domain Identity Management (SCIM) is an open standard that allows for the automation of user provisioning. It was created in 2011 as it became clear that the technology of the future would be cloud-based. SCIM communicates user identity data between identity providers (such as companies with multiple individual users) and service providers requiring user identity information (such as enterprise SaaS apps). In short, SCIM makes user data more secure and simplifies the user experience by automating the user identity lifecycle management process. Connector that you can build with the Okta ProvisioningProvisioning is the enterprise-wide configuration, deployment, and management of multiple types of IT system resources. Specifically, provisioning provides users access to equipment, software, or services. This involves creating, maintaining and deactivating required business process automation objects and attributes in systems, directories, and applications. Connector SDK or any custom SCIM connector or SCIM server. You do not have to connect to Okta and the on-premises provisioning agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. to test your connector.

The testing utility is part of the Okta Provisioning Connector SDK package, available on the Okta Downloads page. To obtain the Okta Provisioning Connector SDK package, sign in to the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console and select Settings > Downloads. Then click Download for the Okta Provisioning Connector SDK.

The testing utility is contained in the scim-sdk-test.jar in the tester folder of the Okta Provisioning Connector SDK. Full documentation for the testing utility is located in the tester/README.TXT file. The primary focus of the tests is to validate the response from your SCIM connector or SCIM server.

Test data

Test data is located in the .json files in the tester/data directory. You can use or modify these files to test your connector. All the tests assume that the input data is valid. Edit or create the sample data files carefully.

Running Tests

Run the tests by using the scim-sdk-tests.jar file. To see all possible arguments, run the jar without any arguments.

java -jar scim-sdk-tests.jar

Complete testing information including calls, responses, all options, and sample results are shown in the tester/README.TXT file. The following code shows a very typical test call. The minimum number of parameters are passed.

Sample test call

The following is a sample test call:

java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createNewUser -file

data/createNewUser.json

Tester usage

To see all possible arguments, run the jar without any arguments.

java -jar scim-sdk-tests.jar

usage: scim-sdk-tests

The following table details the arguments you can pass.

Argument Description
-arg <propertyName=propertyValue> Pass any property name and value pair for your method to use.
-expectResults <true|false> Set test expectations on if results should come back from the connector for the current method. This can be used with the following methods: checkUserExists, downloadUsers, downloadGroups, and importUserProfile.
-file <fileName> The data file to use as input for the current method. Sample files are provided in data directory of testing utility package.
-header <headerName=headerValue> Any additional HTTP header you want sent to the SCIM server. For example, X-Internal-AuthHeader=secret
-method <methodName>

createNewUser

HTTP requests sent:

GET /Users?filter=userName=myemail@domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https)..com&startIndex=1&count=100

POST /Users

If testing connector built using Okta Connector SDK, the tester passes a User object to create a new user using your connector. Tests the connector method SCIMService.createUser

createPendingUser

Http requests sent:

POST /Users

If you are testing a connector built using the Okta Connector SDK, the tester passes a User object to create a pending user using your connector. It tests the connector method SCIMService.createUser.

downloadUsers

HTTP requests sent:

GET /Users?startIndex=1&count=100

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to return the full list of users. It tests the connector method SCIMService.getUsers (without a filter).

checkUserExists

HTTP requests sent:

/Users?filter=userName=myemai@domain.com&startIndex=1&count=100

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector if a specific user already exists. It requires the following additional properties: userIdFieldName and userIdFieldValue. It tests the connector method SCIMService.getUsers (with a filter).

importUserProfile

HTTP requests sent:

GET /Users/<Id>

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to return a single user, passing it the user's ID. It requires the additional property, id. It tests the connector method SCIMService.getUser

activateUser

HTTP requests sent:

PUT /Users/<id>

If you are testing connector built with Okta Connector SDK, the tester queries your connector to activate an existing user. It tests the connector method SCIMService.updateUser.

deactivateUser

HTTP requests sent

PUT /Users/<id>:

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to deactivate an existing user. It tests the connector method SCIMService.updateUser.

reactivateUser

HTTP requests sent:

PUT /Users/<id>

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to reactivate an existing user. It tests the connector method SCIMService.updateUser.

pushPasswordUpdate

HTTP requests sent:

PUT /Users/<id>

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to update the password of an existing user. It tests the connector method SCIMService.updateUser pushProfileUpdate – Okta asks your connector to update the properties of an existing user. It tests the connector method SCIMService.updateUser.

deleteGroup

HTTP requests sent:

DELETE /GroupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups./<id>

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to delete a group. It tests the connector method SCIMService.deleteGroup.

updateGroup

HTTP requests sent:

PUT /Groups/<id>

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to update a group. It tests the connector method SCIMService.updateGroup.

createGroup

HTTP requests sent:

POST /Groups

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to create a group. It tests the connector method SCIMService.createGroup.

getGroupById

HTTP requests sent:

If you are testing a connector built with the Okta Connector SDK, the tester queries your connector to return a group based on the ID. It tests the connector method SCIMService.getGroup.

downloadGroups

HTTP requests sent:

GET /Groups?startIndex=1&count=100

If you are testing a connector built with the Okta Connector SDK, the tester asks your connector to return the full list of groups. It tests the connector method SCIMService.getGroups.

getImplementedUserManagementCapabilities

HTTP request sent:

GET /ServiceProviderConfigs

If you are testing a connector built with the Okta Connector SDK, the tester asks your connector to return the list of UserManagementCapabilities your connector has implemented. Tests the connector method SCIMService.getImplementedUserManagementCapabilities

-url <url> The URL of the SCIM server to use. Example:http://acme.com:8080

Examples

The default implementation provided by Okta assumes that the appname is onprem_appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. and that the examples below and the input data files in the data folder use the custom schema name (urn:okta:onprem_app:1.0:user) for the App User custom schemas. When you implement the connector you need to use the correct appname.

Top