Description
The ConductorOne connector uses the ConductorOne REST API to bring in two independent things, each with its own tick box:
- The IGA tool itself - ConductorOne's users and their ConductorOne roles.
- The systems it governs - every app ConductorOne manages, added as a child system with its accounts (app users), entitlements and who holds each entitlement.
OrbisID can also write its risk classification back to ConductorOne.
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 |
|---|
| ConductorOne REST API (HTTPS) | 443 TCP | OAuth 2.0 client credentials with a signed client assertion |
What OrbisID Discovers
| Data | Source | Shown in OrbisID as |
|---|
| Users | GET /api/v1/users | Accounts on the ConductorOne system (The IGA tool itself) |
| ConductorOne roles | GET /api/v1/iam/roles and each user's roles | Entitlements such as ConductorOne Super Administrator; administrative roles are privileged |
| Apps | GET /api/v1/apps | Child systems named <this system> - <app> (Systems it governs) |
| App users | GET /api/v1/apps/{id}/app_users | Accounts on each app's child system |
| Entitlements | GET /api/v1/apps/{id}/entitlements | Entitlements on each app's child system, with their current ConductorOne risk level |
| Who holds what | GET /api/v1/apps/{id}/entitlements/{id}/users | Account memberships of each entitlement |
Connection Requirements
API client
Create an API client in ConductorOne (Settings → API keys, or your personal API keys) and copy the client ID and client secret. The secret is a long secret-token:... value; OrbisID uses it to sign a short-lived request for an access token, the same way ConductorOne's own tools do, and never sends the secret itself. For scanning the client needs read access; for write-back create a second client allowed to update entitlements, in its own OrbisID credential.
Credential Mapping
| OrbisID Field | ConductorOne Value |
|---|
credential.username | Client ID |
credential.password | Client secret (secret-token:...) |
system.ipAddress (the IP Address / Hostname field) | Tenant host, e.g. acme.conductor.one |
Configuration Steps
- Create the API client in ConductorOne and a credential for it in OrbisID.
- Go to Systems → Add System and choose ConductorOne.
- Set IP Address / Hostname to your tenant host, e.g.
acme.conductor.one.
- Under What to bring in, tick The IGA tool itself, Systems it governs, or both.
- Click Test Connection, then Save and scan the system.
Link a governed app to the system OrbisID scans directly to reconcile access.
Write-back
ConductorOne stores a risk level on entitlements, chosen from your tenant's risk levels; it has no privileged flag. OrbisID therefore writes the risk level only, on entitlements. The risk level mapping holds risk level names (default Low, Medium, High, Critical), which OrbisID looks up in your tenant when writing - change the mapping if your risk levels are named differently.
Troubleshooting
| Symptom | Cause |
|---|
| "client secret is not in the expected format" | The password is not the full secret-token:... secret |
| "authentication failed" | Wrong client ID, or the client was deleted |
| "denied ... lacks permission" | The API client cannot read that data |
| Write-back fails with "no risk level named ..." | The mapping uses a name that does not exist in your tenant |