> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OneLogin

> Connect your OneLogin (One Identity) tenant to Oleria to continuously discover and map users, groups, roles, applications, and activity, and take governance actions directly from Oleria.

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. This page provides step-by-step guidance for connecting OneLogin to 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.

<Note>
  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](#known-limitations).
</Note>

## 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`).

<Note>
  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.
</Note>

## Create an API credential pair in OneLogin

<Steps>
  <Step title="Open API Credentials">
    Log in to OneLogin Administration and navigate to **Developers** -> **API Credentials**.
  </Step>

  <Step title="Create a new credential">
    Select **New Credential** and give it a descriptive name, such as "Oleria Integration".

    <Note>
      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 governance actions (disabling users, managing group and role membership, and application assignment) directly from Oleria.
    </Note>
  </Step>

  <Step title="Copy the credentials">
    Save the credential, then copy the **Client ID** and **Client Secret**.

    <Warning>
      The Client Secret is only shown once at creation time. Store it securely - you will not be able to retrieve it again from OneLogin.
    </Warning>
  </Step>
</Steps>

## Connect OneLogin to Oleria

<Steps>
  <Step title="Open the integration">
    Log in to your Oleria workspace, navigate to **Integrations**, and select **OneLogin**.
  </Step>

  <Step title="Complete the connection form">
    Fill in the connection form with the credentials from the API credential pair:

    | Field              | Notes                                                                               |
    | :----------------- | :---------------------------------------------------------------------------------- |
    | OneLogin Subdomain | Required. The part of your OneLogin URL before `.onelogin.com`, for example `acme`. |
    | Client ID          | Required. The Client ID from the API credential pair.                               |
    | Client Secret      | Required. The Client Secret issued alongside the Client ID.                         |
  </Step>

  <Step title="Authenticate">
    Select **Authenticate** to validate and save the integration. Oleria checks the credentials against OneLogin before saving.
  </Step>

  <Step title="Verify the connection">
    Verify the OneLogin integration status from the connected integrations page. After the first sync completes, you can review the discovered users, groups, roles, and applications in your Oleria workspace.
  </Step>
</Steps>

## Governance 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.

<Note>
  A **Read-only** credential will connect and sync successfully, but any governance action will fail when Oleria attempts to apply it, since OneLogin does not expose an API to distinguish scope ahead of time.
</Note>

## 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's own API credentials are not modeled as a non-human identity.** OneLogin has no confirmed endpoint for enumerating API credential pairs, so the credential used for this integration does not appear as a discovered principal.
* **Joiner (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.
* **Some pagination behavior is unverified against high-volume tenants.** Groups, roles (privileges), and MFA factor lookups are expected to return complete results for typical tenant sizes; very large tenants should confirm complete sync coverage with Oleria support. **Activity (audit log) pagination is the least verified of these** - it is inferred by analogy to other OneLogin endpoints rather than confirmed, so tenants with high event volume should not assume the audit trail sync is exhaustive without checking with Oleria support.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).