Skip to main content
Connect Ironclad to Oleria to see who has access to your Ironclad company: its users, its groups, and who holds an administrator seat. Oleria reads identity and access data through an Ironclad OAuth client application that acts as an Ironclad user you choose, so you can see where access is over-provisioned and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Ironclad company:
  • Accounts - every user in your Ironclad company, with their name, email address, title, department, and whether they’re active. Oleria also shows each user’s sign-in method (password, magic link, SAML single sign-on, or Google sign-in) and marks users who sign in through SAML or Google as requiring single sign-on.
  • Administrator standing - direct members of Ironclad’s built-in Administrators group are marked as administrators, with the Administrator account role. Every other user gets the Member account role. See Known limitations.
  • User groups - every group and its direct members. Oleria labels Ironclad’s default Administrators and Everyone groups as built-in, groups provisioned by your identity provider as synced, and all other groups as custom.
  • Activity - events from Ironclad’s audit log, such as sign-ins, sign-outs, company setting changes, single sign-on configuration changes, and password updates. Oleria keeps every other audit event too, under its Ironclad event name. Activity requires Ironclad’s Security & Data Pro add-on - see Prerequisites.
Oleria refreshes users and groups on its regular sync schedule. Ironclad makes audit-log data available with a delay of up to 36 hours, so Oleria imports each event about 36 hours after it happens. Recent activity appears in Oleria later than users and groups.
Oleria doesn’t import contracts, workflows, records, or documents. This integration covers identity and access governance for users and groups only.

​
Prerequisites

  • An Ironclad company on one of these environments: North America (ironcladapp.com), Europe (eu1.ironcladapp.com), or Demo (demo.ironcladapp.com).
  • An Ironclad administrator who can register an OAuth client application under Company Settings > API. If you don’t see this page, contact Ironclad about API access for your company.
  • An Ironclad user for API calls to run as. The user must be a direct member of the Administrators group, not get its permissions through another group. Oleria acts with this user’s Ironclad permissions.
  • Optional: Ironclad’s Security & Data Pro add-on, to collect audit-log activity.
  • Admin access to the Oleria workspace.
Use a dedicated Ironclad user as the run-as user instead of a named person’s account. If that user is deactivated, leaves the company, or loses the permissions of the Administrators group, syncs and actions can stop working.

​
Register an OAuth client application in Ironclad

1

Create the app

Sign in to Ironclad as an administrator. Go to Company Settings > API and create a new OAuth client application for Oleria.
2

Enable the Client Credentials grant

Enable the Client Credentials grant type for the app. Oleria doesn’t use any other grant type.
3

Grant the scopes

Grant the app the scopes for what you want Oleria to do:
4

Copy the credentials

Copy the app’s client ID and client secret. You need both to connect Ironclad to Oleria.
Grant the two public.export scopes only if your company has the Security & Data Pro add-on. If the app has these scopes but Ironclad refuses the audit-log export, the activity sync fails every time it runs. To stop collecting activity, remove both public.export scopes from the app. Oleria then skips activity and keeps syncing users and groups.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to Ironclad’s own documentation.

​
Connect Ironclad to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Ironclad.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria requests a token with the sync scopes, reads your Ironclad company, and checks that the run-as user can list users and groups before it saves anything. Find the newly connected company on the Connected tab of your Oleria Integrations page.
Authenticate checks the two scopes Oleria needs to sync users and groups. It doesn’t check the activity or action scopes. Confirm the data after the first sync, as described in Verify the integration.

​
Verify the integration

Confirm the Ironclad company appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users and groups appear in your Oleria workspace, and that members of the Administrators group are marked as administrators. If you granted the activity scopes, allow at least 36 hours, plus one sync, for audit-log activity to appear.
When you edit the integration, you can change the client ID, client secret, and run-as user email. Leave Client secret blank to keep the stored secret. The new credentials must belong to the same Ironclad company. To connect a different company or region, add a new integration.

​
Remediation actions

Oleria can take these actions in Ironclad. Each one runs with the Ironclad permissions of the run-as user:
  • Deactivate a user and reactivate a user. Requires the scim.users.readUsers and scim.users.updateUsers scopes.
  • Add a user to a group and remove a user from a group. These actions change direct group membership. Requires the scim.groups.readGroups, scim.groups.updateGroups, and scim.users.readUsers scopes.
If the OAuth client application doesn’t have an action’s scopes, that action isn’t available for the integration. Keep these limits in mind when you use these actions:
  • Oleria reads the user or group before it changes anything. If the user is already in the requested state, Oleria makes no change. If Ironclad doesn’t return a group’s member list, Oleria doesn’t remove anyone from that group, because it can’t confirm who’s a member.
  • After a change, Oleria checks that Ironclad applied it. If Ironclad accepted the change but Oleria can’t confirm it yet, the action succeeds, is marked unconfirmed, and can still be reverted. Oleria never sends a write of its own to undo an action.
  • If Ironclad returns an error but the user or group still ends up in the requested state, the action also succeeds and is marked unconfirmed.
  • Removing a user from a group removes only that member. If other members leave the group while the action runs, Oleria doesn’t add them back. If the whole group is emptied, the action fails and lists the removed members so you can restore them in Ironclad.
  • Reverting an action undoes only the change that action made. Reverting a reactivation or an add always takes the access back. Reverting a deactivation or a removal gives access back, so Oleria does it only when it can tell the change was this action’s. If Ironclad returned an error for the action’s change, or the user or group changed after the action, Oleria doesn’t revert it. Restore the access manually in Ironclad instead. After several removals from one group, usually only the last one can be reverted automatically.
  • Oleria won’t deactivate the run-as user, or remove it from a group, because that would disconnect the integration. Actions that remove access run only while the run-as user is a direct member of the Administrators group, so Ironclad always keeps an administrator.
  • Oleria can’t delete users or change group permissions.

​
Known limitations

  • Activity needs the Security & Data Pro add-on. Ironclad provides audit-log data only with this add-on. Without it, Oleria doesn’t import activity. Audit-log activity is imported about 36 hours after it happens.
  • No actor for changes made through the API. Ironclad records changes made through its API as <System User>, so these events, including changes Oleria makes, have no actor in Oleria.
  • No last-login or dormancy data on accounts. Ironclad’s API doesn’t report when a user last signed in, so Oleria can’t flag dormant accounts from account data. Sign-ins appear as activity when the activity sync is on.
  • No MFA status. Ironclad’s API doesn’t report multi-factor authentication settings.
  • Administrator standing comes only from the Administrators group. Ironclad grants permissions through groups, and its API doesn’t expose group permissions or seat types. A user who gets administrator-level permissions from a custom group is shown as a Member.
  • No roles or role permissions. Ironclad has no role API, so Oleria doesn’t import roles or what each group grants.
  • No non-human identities or AI agents. Ironclad’s API doesn’t list OAuth client applications, access tokens, or AI agents, so Oleria doesn’t discover non-human identities or AI agents.
  • Documented regions only. Oleria connects only to ironcladapp.com, eu1.ironcladapp.com, and demo.ironcladapp.com. Other Ironclad environments, such as separately purchased sandboxes, aren’t supported.
  • Contracts, workflows, and records aren’t inventoried. Oleria doesn’t import contracts, workflows, records, or the access to them.

​
Contact us

For questions about this integration, contact us at support@oleria.com.