Skip to main content

SailPoint Identity Security Cloud (IdentityNow)

Visualize your SailPoint Identity Security Cloud tenant in the JupiterOne graph — the identities ISC correlates across every connected source, the sources themselves, and the access model of roles, access profiles and entitlements built on top of them. Each source account is linked to the identity it correlates to, so a person can be traced to every account they hold, and uncorrelated orphan accounts stand out. Governance groups, identity profiles, separation-of-duties policies and certification campaigns are ingested alongside, letting you query privileged entitlements, role assignments and certification coverage, and monitor changes through queries and alerts.

Installation​

Prerequisites​

  • A SailPoint Identity Security Cloud tenant. ISC was previously branded IdentityNow; the separate SailPoint IdentityIQ integration covers the on-premise IdentityIQ product instead.
  • A Personal Access Token (Client ID and Client Secret) created by a user whose user level covers the data you want to ingest.
  • Access to JupiterOne with permission to configure integrations.

Create a Personal Access Token​

The integration authenticates using OAuth 2.0 (client credentials), exchanging a Personal Access Token for a bearer token against https://{tenant}.api.identitynow.com/oauth/token.

To create the token:

  1. Sign in to https://{tenant}.identitynow.com.
  2. Open the user menu and go to Preferences → Personal Access Tokens.
  3. Select New Token and give it a name that identifies JupiterOne.
  4. Copy the Client ID and Client Secret. The secret is shown only once.

The token inherits the authority of the user who created it, so create it as a user whose level covers the collections you intend to ingest.

The integration issues read-only requests.

note

ISC grants API authority by user level — ORG_ADMIN, SOURCE_ADMIN, SOURCE_SUBADMIN, CERT_ADMIN, HELPDESK and so on — rather than by granular scope, and the level required differs per endpoint. ORG_ADMIN covers everything this integration reads. A token created by a narrower user level still works: the collections it cannot read are skipped with a warning on the job, and the rest are ingested normally. See the Authorization tab for the user levels, scopes and endpoints each step uses.

Configure the integration in JupiterOne​

To install the SailPoint Identity Security Cloud integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select SailPoint Identity Security Cloud (IdentityNow). Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the SailPoint Identity Security Cloud account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The Personal Access Token fields below.

Authentication fields​

FieldRequiredDescription
API URLYesYour ISC API host — for example https://acme.api.identitynow.com.
Client IDYesClient ID of the Personal Access Token.
Client SecretYesClient Secret paired with the Client ID. Shown only once when the token is created.

Click Create once all values are provided to finalize the integration.

note

The API URL is the api. host, not the tenant UI URL. The tenant name alone (acme) and the UI host (acme.identitynow.com) are both accepted and converted to the API host for you, as are trailing slashes and a pasted /v2025 suffix. The scheme is always set to https, since the token secret is sent in the request body.

Data sources​

You can narrow what the integration collects from the instance's ingestion source settings.

Ingestion sourceDefaultData collected
IdentitiesEnabledISC identities — the correlated representation of each person across every connected source — and their manager hierarchy.
SourcesEnabledConnected systems aggregated by ISC, such as Active Directory or Workday, with connector, health and owner detail.
Identity ProfilesEnabledConfiguration that maps an authoritative source into identities, and the source each profile derives from.
Governance GroupsEnabledGovernance groups (workgroups) and their identity membership, used to assign shared ownership and approval duties.
Access ProfilesEnabledAccess profiles, which bundle entitlements drawn from a single source, and their source and owner.
RolesEnabledBusiness roles, the access profiles they bundle, their owners, and the identities assigned to them.
Separation of Duties PoliciesEnabledSeparation-of-duties policies defining combinations of access that must not be held together.
Certification CampaignsEnabledAccess certification campaigns and their completion progress.
EntitlementsDisabledFine-grained access grants on each connected source, such as Active Directory group memberships, including which are flagged privileged.
Source AccountsDisabledAccounts on each connected source and their correlation to identities.
Account Entitlement GrantsDisabledWhich entitlements each source account actually holds.

The three disabled sources are the large ones. A sizeable ISC tenant holds over a million entitlements and several million accounts, so they are opt-in rather than on by default.

Account Entitlement Grants is the most expensive to enable: ISC exposes an account's entitlements only one account at a time, so it costs one API request per account. It requires both Source Accounts and Entitlements to be enabled, and it covers at most 500,000 accounts in a single run — if your tenant has more, the job records that the limit was reached.

Entitlements requires Sources to be enabled, because entitlements are collected source by source.

Relationships that span two of these sources are only created when both are enabled. Disabling Identities, for example, does not stop sources, roles or access profiles being collected — it removes the edges that connect them to identities.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​