SailPoint IdentityIQ

Description

The SailPoint IdentityIQ (IIQ) connector uses IdentityIQ's SCIM 2.0 API to bring in two independent things, each with its own tick box:

• The IGA tool itself - who has access to IdentityIQ: its identities, their IdentityIQ capabilities (SystemAdministrator, HelpDesk, ...) and their roles.
• The systems it governs - every application IdentityIQ manages, added as a child system with its accounts and entitlements.

Roles and the role hierarchy (the roles each role requires, permits or inherits) are read whenever either side is on. OrbisID can also write its privilege and risk classification back to IdentityIQ identities.

System Type Classification

Field	Value
System Type	IGA Tool
Default Scan Priority	500

Version Support

OrbisID Edition	Supported
Community	No
Pro	Yes
Enterprise	Yes (including IGA write-back)

Supported Protocol

Protocol	Port	Notes
IdentityIQ SCIM 2.0 (HTTPS)	443 TCP (or your IdentityIQ port)	HTTP Basic authentication, <context path>/scim/v2

What OrbisID Discovers

Data	Source	Shown in OrbisID as
Identities	GET /Users	Accounts on the IdentityIQ system (The IGA tool itself)
Capabilities	The identities' capabilities	Entitlements such as IIQ SystemAdministrator; administrative capabilities are privileged
Role assignments	The identities' roles	Identity memberships of each role
Roles	GET /Roles	Entitlements on the IdentityIQ system, with required/permitted/inherited roles as parent/child relationships
Applications	GET /Applications	Child systems named <this system> - <application> (The systems it governs)
Accounts	GET /Accounts	Accounts on each application's child system
Entitlements	GET /Entitlements	Entitlements on each application's child system; IdentityIQ classifications are kept
Who holds what	The identities' entitlements (application, account, entitlement)	Account memberships of each entitlement

Connection Requirements

IdentityIQ user

Create an IdentityIQ user with SCIM API access (the SCIM Executor capability, or your organisation's equivalent) for scanning. For write-back, use a second user that is allowed to update identities, in its own OrbisID credential.

Credential Mapping

OrbisID Field	IdentityIQ Value
credential.username / credential.password	The IdentityIQ user (HTTP Basic)
system.ipAddress (the IP Address / Hostname field)	IdentityIQ server host name
system.port	IdentityIQ port (leave empty for 443)

Network Requirements

The OrbisID server (or On-Premise Agent) must reach the IdentityIQ server over HTTPS.

Configuration Steps

1. Create the credential in OrbisID.
2. Go to Systems → Add System and choose SailPoint IdentityIQ.
3. Set IP Address / Hostname (and Port if it is not 443).
4. Under Connection, check the Context path (default /identityiq) and Use HTTPS.
5. Under What to bring in, tick The IGA tool itself, Systems it governs, or both.
6. Click Test Connection, then Save and scan the system.

Write-back

IdentityIQ's SCIM API can update identities but not entitlements, roles or applications, so write-back sets two identity attributes on IdentityIQ identities:

Setting	Default	Holds
Identity attribute for Privileged	orbisidPrivileged	true when any of the person's accounts is privileged in OrbisID
Identity attribute for Risk Level	orbisidRiskLevel	The mapped OrbisID risk level (highest of the person's accounts)

Add both attributes to IdentityIQ's Identity ObjectConfig (Global Settings → Identity Mappings) before enabling write-back. They can then be used in IdentityIQ policies, certifications and reports. All other identity attributes are left as they are.

Troubleshooting

Symptom	Cause
"authentication failed"	Wrong username or password
"denied ... lacks SCIM access"	The user does not have SCIM API access
SCIM error 404	Wrong context path, or SCIM is not enabled on this IdentityIQ
Write-back succeeds but values do not appear	The identity attributes are not defined in the Identity ObjectConfig