> ## 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. # Descope > Connect a Descope project to Oleria to discover users, tenants, roles, federated applications, console administrators, access and management keys, and audit activity, and take remediation actions directly from Oleria. Descope is a customer identity (CIAM) platform. Connect a Descope project to Oleria to see who can sign in to the project, what tenants and roles they hold, and who can administer Descope itself. Oleria reads this data from the Descope Management API with a management key. You can then review over-provisioned access and take action directly from Oleria. One Oleria integration covers one Descope project. To connect another project, such as a staging project next to production, add another integration. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Descope project: * **Users** - the project's users, with name, email, login ID, and status. Users that are enabled or invited are shown as enabled, because invited users can already sign in. Users that are disabled, or whose invitation expired, are shown as disabled. Oleria also shows each user's last sign-in, enrolled authentication methods, and MFA and SSO status. Users that hold one of Descope's system permissions (**Super User**, **User Admin**, **SSO Admin**, or **Impersonate**) are marked as administrators. Descope test users aren't synced. * **Groups** - two kinds: * **Tenants** - each tenant is shown as a group. Its members are the users and access keys that belong to the tenant. * **SCIM and SSO groups** - the groups inside each tenant that were provisioned through SCIM or created at SSO sign-in, with their members. * **Roles** - the project's roles and tenant roles, and who holds them. A project role granted inside a tenant is shown as a separate tenant-scoped role named ` @ `, so each grant can be reviewed and removed on its own. Roles that a tenant's SSO configuration maps to SCIM or SSO groups are shown as roles of those groups. * **Applications** - federated applications, the OIDC and SAML applications Descope signs users in to. Users get access directly or through a tenant the application is assigned to. * **Console administrators** - the Descopers who can sign in to your Descope Console, with the console roles that cover this project. Company admins are marked as super administrators. Descopers whose roles don't cover this project are still shown, without a role. * **Non-human identities (NHIs)**: * **Access keys** - the project's machine-to-machine keys, shown as API tokens. A key bound to a user is shown as a personal access token, linked to the user it acts as. SCIM provisioning keys are included. * **Management keys** - your company's management keys, shown as API tokens, with the management key roles that apply to this project. * **Inbound apps** - third-party OAuth applications, shown as applications. Oleria shows which users consented to each app, and the scopes they granted. * **Descope (system)** - one account that stands for Descope itself. Oleria uses it as the actor for events that Descope writes on its own. Keys show their status (active, disabled, or expired), creation and expiry dates, roles, and creator when Descope records it. Their last-used date comes from the audit log. * **Activity** - events from the Descope audit trail, such as: * sign-ins and failed sign-ins, including Descope Console sign-ins and impersonation * user creation, changes, deletion, and disabling or enabling * role, permission, and tenant changes * password and SSO enforcement changes * access key and management key creation, changes, and deletion * inbound app consents granted and revoked Events Oleria doesn't recognize are kept as custom events. ## Prerequisites * A Descope project, on any plan. * A Descope Console account that can create management keys in your company, such as a **Company Admin**. * Admin access on the Oleria platform to add a new integration. ### Permissions Oleria uses one management key for both discovery and remediation actions. The key's roles decide what Oleria can read and change: | Role in Descope | Machine name | Used for | | :- | :- | :- | | **Asset Management - Read Only** | `project-asset-mgmt-read` | Users, access keys, tenants, and SCIM and SSO groups. Required. | | **Infra Management - Read Only** | `project-infra-read` | Roles, tenant SSO settings, federated applications, and inbound apps and their consents. Required. | | **Audit Handling** | `project-audit` | Activity, and the last-used dates, password-change dates, and creators that come from the audit log. Without it, Oleria syncs no activity. | | **Descopers - Read & Write** | `company-descopers-read-write` | Optional. Console administrators. Company-wide, with no read-only variant; see the warning below. Oleria only reads Descopers. | | **Management Keys - Read & Write** | `company-mgmt-keys-read-write` | Optional. Management keys, and required to disable management keys. Company-wide, with no read-only variant; see the warning below. | | **Asset Management - Read & Write** | `project-asset-mgmt-read-write` | Required for remediation actions. It includes the read access of **Asset Management - Read Only**. | The project roles also work as company-level roles (for example, `company-asset-mgmt-read`) or tag-level roles. A **Full Access** role covers all of them. If the key can't read Descopers or management keys, Oleria still syncs the rest of the project. If the key can't read SCIM and SSO groups, tenant SSO settings, federated applications, or inbound apps, Oleria skips them and syncs the rest of the project. If one of these is missing after the first sync, grant the key **Full Access** for the project or contact support. > [!WARNING] > > **Descopers - Read & Write** and **Management Keys - Read & Write** have no read-only variants and apply to your whole Descope company. A key with them can change console administrators and every management key in the company, in every project. Grant them only if you want Oleria to inventory console administrators and management keys, or to disable management keys. Store and rotate this key as you would a company admin credential. > [!NOTE] > > Use a dedicated management key for this integration. Oleria never disables the management key it connects with. ## Create a management key in Descope **1. Copy the Project ID** In the Descope Console, select the project you want to connect, go to **Project Settings** -> **General**, and copy the project ID. **2. Create the management key** Go to **Company** -> **Management Keys** and create a key. Name it `Oleria`, and choose an expiration that fits your policy: 30, 60, or 90 days, or never. Associate the key with the project you want to connect, or leave it company-wide. Descope sets this association when you create the key, and you can't change it later. **3. Grant the roles** Grant the project roles listed in [Permissions](#permissions) for the project. If you want Oleria to inventory console administrators and management keys, also grant the company roles **Descopers - Read & Write** and **Management Keys - Read & Write**. Read the [warning about these roles](#permissions) first. **4. Set permitted IPs (optional)** If you restrict the key to permitted IPs, add Oleria's IP addresses. Contact [support@oleria.com](mailto:support@oleria.com) for the current list. **5. Copy the key** Copy the management key. Descope shows it only once. > [!NOTE] > > The Descope Console changes over time. If these steps don't match what you see, refer to Descope's [management keys](https://docs.descope.com/management#management-keys) documentation. ## Connect Descope to Oleria **1. Open the integration** Sign in to your Oleria workspace, navigate to **Integrations**, and select **Descope**. **2. Complete the connection form** Fill in the connection form: | Field | Notes | | :- | :- | | Project ID | Required. The project ID from **Project Settings** -> **General**. Oleria finds your project's regional API host from it. | | Management Key | Required. The management key you created. | | Base URL (Descope Private Cloud only) | Optional. Leave it empty unless your project runs on Descope Private Cloud or needs a different regional API host. Must be an `https` address on `descope.com` or `descope.app` with no path, for example `https://api.euc1.descope.com`. Custom domains aren't accepted. | **3. Authenticate** Select **Authenticate**. Oleria checks that the management key can reach the project and has **Asset Management - Read Only** and **Infra Management - Read Only**, or roles that include them, before it saves the integration. If a role is missing, Oleria names it. A missing **Audit Handling** role doesn't block the connection. The integration is named after your Descope project. ### Edit the connection You can change the **Management Key** and **Base URL** of an existing integration. Leave **Management Key** blank to keep the stored key. You can't change the **Project ID**. To connect a different project, add a new integration. ## Verify the integration Confirm the Descope integration appears on the **Connected** tab of your Oleria **Integrations** page. After the first sync completes, review the discovered users, tenants, groups, roles, federated applications, console administrators, NHIs, and activity in your Oleria workspace. > [!NOTE] > > If you rotate the management key in Descope, the old key stops working immediately. Update the **Management Key** in Oleria by editing the integration. Discovery stops until you do. ## Remediation actions Oleria runs actions with the integration's management key. Each action needs the roles listed below. | Action | What it does | Revert | | :- | :- | :- | | Create user | Creates a user with the email address as the login ID, and adds the user to the requested tenants. Descope creates new users as invited, which lets them sign in, so Oleria then disables the user unless you choose to activate it. If a user with that login ID already exists, nothing changes. If the status change fails, Oleria deletes the user it just created. | Supported - deletes the user the action created. | | Delete user | Deletes the user from the project. | Not supported - Descope can't restore a deleted user. | | Disable user accounts | Sets the user's status to disabled. | Supported - restores the previous status. A user who was invited is restored as enabled. A user whose invitation had expired isn't restored. | | Enable user accounts | Sets the user's status to enabled. Invited users can already sign in, so nothing changes for them. | Supported - restores the previous status, unless the user's invitation had expired. | | Activate user accounts | Changes an invited user's status to enabled. Disabled users are refused; use **Enable user accounts** for them. | Supported - sets the user back to invited. If Descope refuses that, the revert fails and the user stays enabled. | | Revoke user sessions | Signs the user out of every Descope session. | Not supported - the user signs in again. | | Add user to role | Grants the role to the user: a project role at the project level, a tenant role in its tenant, or a tenant-scoped role in that tenant. For a tenant role or a tenant-scoped role, the user must already be in the tenant. | Supported - removes the role again. | | Remove user from role | Removes that one grant of the role. The user's other grants of the same role, at the project level or in other tenants, don't change. | Supported - grants the role again, if the user is still in the tenant. | | Add user to group | Adds the user to a tenant. Descope can restore tenant roles the user held before an earlier removal; Oleria removes any that aren't the tenant's default roles and records them in the action result. Tenants only. | Supported - removes the user's tenant roles, then removes the user from the tenant. Roles Oleria removed aren't granted again. | | Remove user from group | Removes the user's roles in a tenant, then removes the user from the tenant, so the roles can't come back on a later add. Tenants only. | Supported - adds the user back to the tenant and restores exactly the tenant roles the user held. | | Create group | Creates a tenant with the name you enter. If a tenant with that name already exists, nothing changes. | Supported - deletes the tenant the action created, but only while it has no users. | | Assign user to application entitlement | Assigns a federated application to the user. Disabled applications are refused. | Supported - removes the assignment. | | Remove user from application entitlement | Removes the user's direct assignment to a federated application. Access that the user gets through a tenant stays. To remove it, use **Remove group from application entitlement**, or remove the user from the tenant. | Supported - assigns the application again. | | Assign group to application entitlement | Assigns a federated application to a tenant, which gives every user in the tenant access. Disabled applications are refused. Tenants only. | Supported - removes the application from the tenant. | | Remove group from application entitlement | Removes a federated application from a tenant. Users who are assigned the application directly keep their access. Tenants only. | Supported - assigns the application to the tenant again. | | Disable NHI accounts - access key | Deactivates the access key, including keys bound to a user. Disabling a SCIM provisioning key stops SCIM provisioning for its tenant. | Supported - reactivates the key. | | Disable NHI accounts - management key | Deactivates the management key. | Supported - reactivates the key. | Each action needs these management key roles: | Action | Required roles | | :- | :- | | Create user, Delete user, Disable user accounts, Enable user accounts, Activate user accounts, Revoke user sessions, Add user to group, Remove user from group, Create group | `project-asset-mgmt-read-write` | | Add user to role, Remove user from role, Assign user to application entitlement, Remove user from application entitlement, Assign group to application entitlement, Remove group from application entitlement | `project-asset-mgmt-read-write`, `project-infra-read` | | Disable NHI accounts - access key | `project-asset-mgmt-read-write` | | Disable NHI accounts - management key | `company-mgmt-keys-read-write` | When the key has **Management Keys - Read & Write**, Oleria checks its roles before an action runs. Without it, Oleria can't read the key's roles, so an action without the write role fails when Oleria makes the change. Oleria refuses these actions and sends no change to Descope: * Disabling the management key the integration connects with. Oleria also refuses to disable any management key when it can't identify that key, for example when the key lacks **Management Keys - Read & Write**. * Changing SCIM or SSO group membership or application assignments, or creating a user in one of these groups. These groups are managed by the tenant's identity provider; change them there. * Changing Descopers, management keys, or inbound apps with user actions, and assigning console or management key roles to users. * Disabling inbound apps. Descope has no disabled state for them, only irreversible secret rotation, consent deletion, or app deletion. * Disabling the **Descope (system)** account. Keep these points in mind: * If the target is already in the requested state, the action succeeds without making a change, and there's nothing to revert. * Reverting checks the target first. If it changed after the action ran, or no longer exists, Oleria leaves it as is. ## Known limitations * **One project per integration.** Descope keeps users, tenants, roles, keys, and audit events per project. Add one integration for each project you want to see. * **Company-level data repeats per project.** Descopers and management keys belong to your Descope company, so they appear in every Descope integration for that company. * **Activity history depends on your plan.** Descope keeps audit events for 1 week on the Free plan and 1 month on the Pro and Growth plans, and its API returns at most the last 30 days. The first sync imports activity from that window only. Last-used dates of keys and Descopers' last sign-in come from the newest audit events Oleria reads on each sync. That covers up to the last 30 days, and less on busy projects, because Oleria reads at most about 10,000 of the newest events for these fields. A key or Descoper with no event in that range has no last-used date. The creator of a management key or inbound app is shown only when Oleria has seen its creation event. * **Last password change comes from audit events.** Descope doesn't store a password-change date on the user. Oleria shows one only when a password was created or changed within that range. * **MFA status comes from enrolled factors.** Descope defines MFA in its flows, which its API doesn't expose. A user with an enrolled authenticator app, passkey, or push factor is shown with MFA required. For other users, MFA status isn't known, even if a flow asks them for a one-time code. MFA and SSO status aren't known for Descopers. * **SCIM and SSO groups are read-only.** The tenant's identity provider manages them, so Oleria has no actions for them. * **Descopers are read-only.** Descope's API can't disable a Descoper, so Oleria has no actions for them. Manage console administrators in the Descope Console. * **Not synced yet.** Tenant SSO identity provider configurations and outbound apps, which store third-party tokens for users, aren't synced. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.