What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your SailPoint tenant:- Identities - the canonical, cross-source-correlated principal for every person SailPoint governs.
- Accounts - each per-source account (Active Directory, Workday, a custom connector, and so on) that rolls up into an Identity.
- Sources - every connected downstream system, represented as a governed resource.
- Roles, Access Profiles, and Entitlements - all three of SailPoint’s assignable-access objects, including how Access Profiles and Entitlements nest inside Roles.
- Governance Groups - SailPoint’s group construct, along with group membership.
- Personal Access Tokens and OAuth API clients - SailPoint API credentials, as non-human identities. Discovery requires a Personal Access Token created by a user: Personal Access Tokens need the
sp:all-personal-access-tokens:readscope, and OAuth API clients need thesp:oauth-client:readscope. An OAuth API Client connection doesn’t discover them. Personal Access Tokens are linked to their owner. Each one shows its scopes and last use, and Personal Access Tokens also show their expiry. - Separation-of-duties (SoD) violations - identities that appear in the latest completed violation report of a SoD policy. Oleria only reads reports. It never starts one, so findings are as fresh as the last report you run in SailPoint.
- Administrators - identities that hold a SailPoint administrative user level (for example Org Admin, Help Desk, Certification Admin, Role Admin, or Source Admin) are flagged as administrators, with their levels shown as secondary roles. This needs the optional
idn:user-level:readscope and a Personal Access Token created by an Org Admin. - Activity - audit events from SailPoint, mapped to Oleria’s activity model.
SailPoint has no separate “group” concept tied to a specific source (for example, an Active Directory group is modeled as an Entitlement). Oleria’s Governance Group discovery covers SailPoint’s own cross-source Governance Groups, not source-native groups - those are represented as Entitlements instead. See Known limitations.
Prerequisites
- A SailPoint ISC credential using OAuth2 Client Credentials - either of the following can connect:
- A Personal Access Token (PAT), which you create under Preferences -> Personal Access Tokens (recommended - see the note below). Create it as an Org Admin. Oleria reads sources, accounts, and roles, and Org Admin is the only user level that can read all three.
- An OAuth API Client, which you create under Admin -> Global -> Security Settings, on the API Management tab.
- Your SailPoint tenant name - the part before
.identitynow.comin your SailPoint URL (for example,acmeforacme.identitynow.com). If your tenant uses a custom URL, find the tenant name as Org Name under Dashboard -> Overview. If you’re on a demo or trial tenant (*.identitynow-demo.com), paste the full hostname instead of the bare subdomain - see the Tenant field below.
Use a Personal Access Token. SailPoint accepts access requests only from a token with a user context, so role, access profile, and entitlement actions don’t work with an OAuth API Client. If Data Segmentation is enabled in your tenant, an OAuth API Client also fails to search roles, entitlements, and identities, which Oleria reads during sync.
Required scopes
Select these scopes when you create the credential. Without scopes, SailPoint assigns only its default scope, which doesn’t grant any endpoint Oleria reads. A token never has more rights than its owner’s user level, andsp:scopes:all grants every right of that user level. Org Admin is the only user level that covers everything Oleria reads. Listing sources allows Org Admin, Source Admin, Source Sub-Admin, or Role Sub-Admin. Listing accounts allows Org Admin, Source Admin, Source Sub-Admin, or Helpdesk. Listing roles allows Org Admin, Role Admin, or Role Sub-Admin. Reading administrative user levels (optional) needs Org Admin. A token created at any other user level can’t read everything this page describes.
Create a credential in SailPoint
1
Choose a credential type
Decide whether to use a Personal Access Token or an OAuth API Client. Both sign in the same way, but an OAuth API Client can’t run role, access profile, or entitlement actions, and it can’t sync when Data Segmentation is enabled. Use a Personal Access Token.
2
Generate the credential
For a Personal Access Token, select your user icon, then Preferences -> Personal Access Tokens -> New Token. Enter a description in What is this token for?, set an expiration date, select the scopes from Required scopes, and select Create Token.For an OAuth API Client, go to Admin -> Global -> Security Settings, open the API Management tab, and select Create API Client. Enter a Description, select the Client Credentials grant type, select the scopes from Required scopes, and select Create.
A Personal Access Token expires after 6 months unless you set another date. When it expires, Oleria can’t sync. SailPoint doesn’t let you change a token’s expiration date, so before then, create a new token and enter its Client ID and Client Secret by editing the integration in Oleria.
3
Copy the Client ID and Client Secret
Save the credential, then copy the Client ID and Client Secret.
Connect SailPoint to Oleria
1
Open the integration
Log in to your Oleria workspace, navigate to Integrations, and select SailPoint.
2
Complete the connection form
Fill in the connection form with the credential you generated:
3
Authenticate
Select Authenticate to validate and save the integration. Oleria checks the credentials against SailPoint before saving.
4
Verify the connection
Verify the SailPoint integration status from the connected integrations page. After the first sync completes, you can review the discovered identities, accounts, roles, access profiles, entitlements, and governance groups in your Oleria workspace.
Governance actions
With a suitably scoped credential, Oleria can take the following actions directly against SailPoint:- Enable or disable a user’s account.
- Assign or remove a Role.
- Assign or revoke an Access Profile.
- Grant or revoke an Entitlement.
- Add or remove a user from a Governance Group.
Role, Access Profile, and Entitlement changes are submitted as SailPoint access requests, which may route through an approval workflow configured in your tenant rather than applying immediately.
Known limitations
- SailPoint administrators need an Org Admin Personal Access Token. Oleria flags holders of SailPoint’s administrative user levels only when the credential is a Personal Access Token created by an Org Admin, with the
idn:user-level:readscope. With an OAuth API Client, or if SailPoint refuses the request, the sync still succeeds but no identity is flagged as an administrator. - Source-native groups appear as Entitlements, not as groups. SailPoint represents a downstream system’s native group (for example, an Active Directory group) as an Entitlement rather than as a distinct group type, so Oleria mirrors that and surfaces it as access rather than group membership.
- Nested Governance Groups are not distinguished. SailPoint does not expose a parent/child field for Governance Groups, so group nesting - if present in your tenant - is not currently reflected.
- Activity actor and target resolution is best-effort. Oleria resolves the actor and target names in SailPoint’s audit events to known identities using a cache built during sync, but resolution is not guaranteed to be exact for every event.
- Joiner (account creation) is not supported. Oleria can disable, enable, and change access for existing SailPoint-governed accounts, but does not create new accounts.
- Certification and access-review actions are not supported. Oleria does not currently trigger or respond to SailPoint certification campaigns.
- Changes in SailPoint may take up to several minutes to appear in Oleria. Oleria applies a short delay before pulling new activity to ensure SailPoint’s own records have settled.