Connector guides

SailPoint IdentityIQ

Connect Warde to SailPoint IdentityIQ through its SCIM API, so it reads applications and access, checks separation of duties before approval, and provisions through a workflow.

With an IdentityIQ engine, IdentityIQ stays the system of record. Warde reads applications, entitlements, roles and accounts through IdentityIQ's SCIM 2.0 API, asks IdentityIQ's policies about separation of duties before a request is approved, and provisions each change by launching a workflow.

#Before you start

You need:

• IdentityIQ 8.x, with its SCIM API reachable at https://<host>/identityiq/scim/v2;
• a way for the instance to reach it. On-premises IdentityIQ usually needs a ServiceNow MID Server;
• the attribute that identifies a person in both IdentityIQ and ServiceNow.

#1. Prepare IdentityIQ

#Create a SCIM user

Create an IdentityIQ identity for Warde and give it the SCIMExecutor capability. Warde signs in to the SCIM API with this user's name and password, using HTTP Basic authentication.

#Choose the provisioning workflow

Warde launches LCM Provisioning for each change by default, with a provisioning plan, flow=AccessRequest and approvalScheme=none, because Warde has already run the approval. To use a workflow of your own, name it in the engine's connector configuration as workflow_name.

The workflow must:

• not stop for an approval or a form;
• not be transient, so Warde can follow its task result;
• finish or move to the background within 30 seconds;
• not set identityRequestId.

#Expose the SCIM API

If the instance reaches IdentityIQ through a reverse proxy or a MID Server, make sure /identityiq/scim/v2 is reachable on that path.

#2. Set the endpoint in ServiceNow

1. Open Connections & Credentials > Connections & Credential Aliases and open SailPoint IIQ.
2. Open its HTTP connection, SailPoint IIQ - connection.
3. Set Connection URL to the SCIM service root, such as https://iiq.example.internal/identityiq/scim/v2. Use the service root, not a specific endpoint.
4. Save.

#3. Add the engine

In Guided Setup step 2, select Add an engine:

Select Create engine, then Test connection.

#Connector configuration

On the engine form in the Admin Workspace, Connector configuration takes JSON:

{ "delta_sync": true, "workflow_name": "LCM Provisioning" }

#4. Bind accounts to users

In Guided Setup step 3, set the engine's pair: an IdentityIQ identity attribute and the matching ServiceNow user field.

#5. Run the first sync

In Guided Setup step 4, select Sync now, then Refresh until the counts settle.

#What Warde reads

Assignments are always a full read, at the full-sweep interval. IdentityIQ keeps no end dates for Warde: Warde removes time-limited access itself when it expires.

#Separation of duties

IdentityIQ is the one engine Warde can ask about separation of duties before approval. For each request line, Warde sends IdentityIQ a provisioning plan to CheckedPolicyViolations, with the person's other open requests, and IdentityIQ answers with any violations of its policies. What Warde does with the answer is set in Separation of duties.

An engine behind a MID Server runs the check after submit rather than on the form, because the form cannot wait on a MID Server round trip.

#What Warde writes

Each change launches the workflow with one provisioning plan, through POST /LaunchedWorkflows. Warde saves the task result id before it acknowledges the launch, then polls it:

A workflow that finishes inside the launch is settled straight away.

When IdentityIQ does not answer. IdentityIQ's SCIM API offers no way to look up a launch by Warde's reference. If a launch times out, a gateway answers instead, or no task result id comes back, Warde cannot tell whether it ran, so the work goes to a person with a note to check IdentityIQ first, and writes to the engine pause. A change that already has a launch is followed, never launched twice.

People with no IdentityIQ account. Warde cannot yet find a person in IdentityIQ who has no account there. A grant for such a person goes to a person.

#Health and troubleshooting

The health check reads /ServiceProviderConfig with the SCIM user's credentials.

#Endpoints Warde calls