Skip to main content
Connect OneLogin to Oleria to gain continuous visibility into who has access to what across your OneLogin tenant. Oleria reads identity, membership, and access data from the OneLogin API - mapping every user, group, role, and application in one place - 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 OneLogin tenant:
  • Users - every user account in your OneLogin directory, enriched with each user’s MFA factors.
  • Groups - OneLogin groups and each user’s group membership.
  • Roles - both standard OneLogin roles and custom privileges, along with each user’s role assignments.
  • Applications - every application configured in OneLogin (represented as resource instances).
  • Activity - audit log events from OneLogin, mapped to Oleria’s activity model.
Groups in OneLogin are flat and single-valued - a user belongs to at most one group at a time, and groups do not nest or grant application/role access directly. See Known limitations.

​
Prerequisites

  • A OneLogin Administration account with access to Developers -> API Credentials.
  • Your OneLogin subdomain - the part of your OneLogin URL before .onelogin.com (for example, acme if you access OneLogin at acme.onelogin.com).
Create a dedicated API credential pair for this integration rather than reusing an administrator’s personal credentials, to ensure continuity if that administrator leaves or changes roles.

​
Create an API credential pair in OneLogin

1

Open API Credentials

Sign in to OneLogin Administration and navigate to Developers -> API Credentials.
2

Create a new credential

Select New Credential and give it a descriptive name, such as “Oleria Integration”.
Choose Read-only scope if you only want Oleria to discover access. Choose Manage All (Read and Write) scope if you also want to perform remediation actions (disabling users, managing group and role membership, and application assignment) directly from Oleria.
3

Copy the credentials

Save the credential, then copy the Client ID and Client Secret.
The Client Secret is only shown once at creation time. Store it securely - you will not be able to retrieve it again from OneLogin.

​
Connect OneLogin to Oleria

1

Open the integration

Sign in to your Oleria workspace, navigate to Integrations, and select OneLogin.
2

Complete the connection form

Fill in the connection form with the credentials from the API credential pair:
3

Authenticate

Select Authenticate to validate and save the integration. Oleria checks the credentials against OneLogin before saving.

​
Verify the integration

Confirm the OneLogin instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, groups, roles, applications, and activity in your Oleria workspace.

​
Remediation actions

With a Manage All scoped credential, Oleria can take the following actions directly against OneLogin:
  • Enable or disable a user’s account.
  • Add or remove a user from a group.
  • Add or remove a role from a user.
  • Assign or revoke a user’s access to an application, by adding or removing the user from the role that carries that application.
A Read-only credential will connect and sync successfully, but any remediation action will fail when Oleria attempts to apply it, since OneLogin does not expose an API to distinguish scope ahead of time.

​
Known limitations

  • Direct application-access assignment is not yet synced. Oleria discovers which applications exist in your tenant, but the specific mapping of which users have access to which application is not yet surfaced as a direct relationship. Application access can currently only be reviewed indirectly through a user’s role assignments.
  • Application assignment is role-mediated. OneLogin has no API to assign or revoke a specific user’s access to a specific application directly - access to an application is granted through the role(s) a user holds. Oleria resolves the role that carries the target application and adds or removes the user from that role.
  • Groups do not grant application or role access. OneLogin groups are membership-only, with no group-to-role or group-to-application assignment. A user’s application and role access comes entirely from their direct role assignments, not their group.
  • Group membership is single-valued. A OneLogin user belongs to at most one group at a time; Oleria reflects this one-to-one relationship rather than a many-to-many membership model.
  • Administrator status is not distinguished. OneLogin does not expose a direct field identifying admin users, so Oleria does not currently flag OneLogin administrators as a separate principal class.
  • OneLogin API credentials aren’t discovered as non-human identities. OneLogin doesn’t offer an API to list API credentials, so Oleria can’t track them as NHIs. This includes the credential this integration uses to connect.
  • Account creation is not supported. Oleria can disable, enable, and change access for existing OneLogin users, but does not create new user accounts in OneLogin.
  • Risk/vigilance signals are not synced. OneLogin’s risk-scoring data is out of scope for this integration.
  • Sync completeness isn’t verified for very large tenants. Groups, roles, and MFA factors are expected to sync completely for typical tenant sizes. For very large tenants, and especially for audit log events in tenants with high event volume, complete sync hasn’t been verified. If your tenant is large, contact Oleria support to confirm your sync, including your audit trail, is complete before you rely on it for compliance.

​
Contact us

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