Connector guides

SailPoint Identity Security Cloud

Connect Warde to SailPoint Identity Security Cloud so it reads sources, roles and access, and sends grants and removals as ISC access requests.

With an ISC engine, ISC stays the system of record. Warde reads its sources, entitlements, roles and access profiles, matches each ISC identity's accounts to a ServiceNow user, and sends every grant and removal to ISC as an access request.

#Before you start

You need:

• an ISC tenant, and the right to create a service identity and a personal access token in it;
• the tenant's API base URL, https://<tenant>.api.identitynow.com;
• the attribute that identifies a person in both ISC and ServiceNow, such as the employee number.

#1. Prepare ISC

#Create a service identity

Create an identity for Warde and give it the ORG_ADMIN user level. Below ORG_ADMIN, ISC lists no entitlements, hides the status of the changes Warde sends, and refuses every removal.

#Create a personal access token

Sign in as the service identity and create a personal access token. Warde stores the token's client ID and secret and exchanges them for a bearer token on each call. ISC's access request APIs need a token that acts as a user, which is why Warde uses a personal access token rather than an API client.

Give the token the scopes the ORG_ADMIN user level allows. If your policy restricts token scopes, keep at least these, which Warde relies on by name:

Note the token's expiry date. When it expires, every call fails until you create a new token and enter it in Guided Setup.

#Make the correlation attribute searchable

ISC search finds only identity attributes marked searchable. Mark the attribute you will use in Bind accounts to users as searchable in ISC.

#Remove ISC approval steps from managed items

ISC applies its own approval steps to access requests, including Warde's. Warde has already run the approval, so an ISC approval step makes every change approved twice. Clear the approval schemes on the sources, roles, access profiles and entitlements Warde manages. The daily approval audit names any managed item that still has an approval step, and engine health shows them.

#2. Set the endpoint in ServiceNow

1. Open Connections & Credentials > Connections & Credential Aliases and open SailPoint ISC.
2. Open its HTTP connection, SailPoint ISC - connection.
3. Set Connection URL to https://<tenant>.api.identitynow.com, with nothing after it.
4. Save.

#3. Add the engine

In Guided Setup step 2, select Add an engine:

Select Create engine, then Test connection. A pass means ISC accepted the token and listed sources.

#Optional settings

On the engine form in the Admin Workspace:

In Warde > Properties, under Inbound sync:

#4. Bind accounts to users

In Guided Setup step 3, set the engine's pair, for example Engine attribute employeeNumber and ServiceNow user field employee_number. Use the attribute you marked searchable.

#5. Run the first sync

In Guided Setup step 4, select Sync now, then Refresh until the counts settle. A large tenant can take hours; the assignment read pauses after three hours and resumes on the next run.

#What Warde reads

Only accounts can be read as a delta in ISC; everything else is a full read at the full-sweep interval.

End dates. ISC keeps a role's end date itself. For entitlements and access profiles, Warde keeps the end date and removes the access when it passes.

Approval audit. A separate job, Warde sync: approval audit, runs daily at 04:00. It finds managed items with an ISC approval step and reads the token's expiry. Sync now does not run it, so those health notes first appear the morning after you connect.

#What Warde writes

Every grant and removal is an ISC access request (POST /v3/access-requests), carrying Warde's reference in its client metadata.

• A grant asks for up to 25 items for up to 10 identities in one request, one account per source per item.
• A removal carries one entitlement.
• Warde polls the request's status. Provisioning that is waiting on verification counts as done. A grant ISC cancels because the person already holds the access counts as done.

Finding the right identity. Warde uses the identity behind the person's account on that source. With no account, it uses the person's single identity on this engine, or searches the correlation attribute. If the search finds two identities, nothing is sent and the request goes to a person.

Refusals. A removal ISC says cannot be revoked, or of something not requestable, goes to a person. A removal refused because one is already outstanding is adopted rather than sent again.

When ISC does not answer. If a request times out or a gateway answers instead of ISC, Warde pauses writes to the engine and, on the next try, looks for the request in ISC by Warde's own submit reference instead of sending it again. If it is still not found after 30 minutes, the work goes to a person and is not sent again.

ISC account enable and disable are not automated; they go to a person.

#Health and troubleshooting

The health check lists one page of sources with the token. Engine health also reports refused reads, managed items with an ISC approval step, and a token close to expiry.

Log lines for this connector start [Warde sync] and [Warde dispatch]. See Health, alerts and logs.

#Endpoints Warde calls