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

# Liferay

> Connect Liferay DXP or Liferay Portal to Oleria to bring users, service accounts, user groups, organizations, roles, sites, permissions, and audit activity into your identity and access graph.

Connect Liferay to Oleria to see who has access to your Liferay instance: its users and service accounts, the user groups, organizations, and roles they belong to, the sites they can reach, and what each role is allowed to do. Oleria reads this data from Liferay's APIs using an OAuth 2.0 application, so you can find over-provisioned and anonymous access and take action directly from Oleria.

The integration works with self-hosted Liferay, Liferay PaaS, and Liferay SaaS, running Liferay DXP or Liferay Portal 7.4 GA112 or later, including the quarterly releases.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Liferay instance:

* **Accounts** - every user, with name, email address, job title, last sign-in, and status. Deactivated users appear as disabled accounts. Administrators are flagged.
* **Service accounts** - Liferay's default service account and the service accounts behind OAuth 2.0 applications, shown as non-human identities.
* **Anonymous access** - a single anonymous account that holds Liferay's **Guest** role, so anything Guest can see shows up as anonymous access.
* **User groups** - every Liferay user group and organization, the organization hierarchy, and their members. A member's organization roles appear on their membership.
* **Roles** - every role in the instance (regular, site, organization, asset library, and account roles), which users hold regular roles directly, and which roles are assigned to user groups and organizations.
* **Resources** - every site (and its parent site), plus any individual item, such as a web content article or a documents folder, that has its own permissions.
* **Permissions** - what each role may do instance-wide, on a site, or on an individual item, and which users have access to each site through membership or a site role.
* **Owners** - site and organization owners and administrators.
* **Activity** - events from the Liferay audit trail, including sign-ins, failed sign-ins, account changes, and role assignments.
* **Authentication posture** - whether SAML single sign-on and email one-time-password MFA are enabled for the instance.

> [!NOTE]
>
> Oleria doesn't read the content of your sites, web content, or documents. It only reads who can access them.

## Prerequisites

* A Liferay user with the **Administrator** role, to create the OAuth 2.0 application.
* A dedicated Liferay user with the **Administrator** role for Oleria to act as. Liferay only lets administrators read role permissions and the audit trail, and change other users.
* Your Liferay instance reachable from the internet over HTTPS on port 443. Liferay SaaS (`*.liferay.com`) and Liferay PaaS (`*.lfr.cloud`) addresses work as is. For a self-hosted instance or a custom domain, contact [support@oleria.com](mailto:support@oleria.com) to have the hostname allowed before you connect.
* Admin access to the Oleria workspace.

## Create an OAuth 2.0 application in Liferay

**1. Open OAuth 2 Administration**

Sign in to Liferay as an administrator, open the **Control Panel**, then go to **Security** -> **OAuth 2 Administration**. Select **New** (+).

**2. Configure the application**

Enter a name, for example `Oleria Integration`, then set:

| Setting | Value |
| :- | :- |
| Client Profile | **Headless Server** |
| Allowed Authorization Types | **Client Credentials** only |
| Client Credentials User | The dedicated Oleria user with the Administrator role |

Select **Save**. Liferay generates a **Client ID** and **Client Secret**.

**3. Grant the scopes**

Open the application's **Scopes** tab and grant:

* **Liferay.Headless.Admin.User** - everything (`Liferay.Headless.Admin.User.everything`), for users, roles, and user groups
* **JSON Web Services** - everything (`liferay-json-web-services.everything`), for user, group, site, permission, and audit reads, and the remediation actions. The `set*` and `unset*` methods the remediation actions use aren't covered by write-only access.

For the MFA and SSO posture, also grant `Liferay.Saml.Admin.REST.everything.read` and `Liferay.Headless.Admin.Configuration.everything.read` where your Liferay version offers them. Without them, Oleria reports MFA and SSO as unavailable. On Liferay Portal CE, which ships no MFA module, MFA is reported as not required and only SSO is unavailable.

Select **Save**.

**4. Copy the credentials**

On the **Info** tab, copy the **Client ID** and **Client Secret** somewhere secure.

> [!WARNING]
>
> If you lose the secret, generate a new one in Liferay and update the integration in Oleria.

## Connect Liferay to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations** -> select **Liferay**.

**2. Complete the connection form**

Select **Continue** and provide the following:

| Field | Notes |
| :- | :- |
| Portal URL | Required. The root address of your Liferay instance, for example `https://portal.example.com`. Use HTTPS, no path, and no port other than 443. |
| Client ID | Required. The Client ID of the OAuth 2.0 application. |
| Client Secret | Required. The Client Secret of the OAuth 2.0 application. |

**3. Confirm the connection**

Select **Authenticate**. Oleria requests a token, checks that the Client Credentials User holds the Administrator role, and rejects the connection if it doesn't. Find the newly connected Liferay instance on the **Connected** tab of your Oleria **Integrations** page.

## Verify the integration

Confirm the Liferay instance appears on the **Connected** tab of your Oleria **Integrations** page. After the first sync completes, you can review the discovered accounts, service accounts, user groups, roles, and sites in your Oleria workspace.

> [!NOTE]
>
> A connection is tied to one Liferay instance at one address. To change the Client ID when editing the integration, enter the Client Secret again. The Portal URL can't be changed: if your instance moves to a new address, or you want to connect a different instance, create a new integration.

## Remediation actions

Every action except **Create group** and **Create user** checks the current state first, changes only what's needed, and confirms the change. Those two are sent once and never retried. Oleria never acts on the Liferay user it signs in as.

| Action | What it does in Liferay | Reversible? |
| :- | :- | :- |
| Disable account | Deactivates the user. | Yes - reactivates the user. |
| Enable account | Activates the user. | Yes - deactivates the user again. |
| Add to group | Adds the user to a user group or organization. | Yes - removes them. |
| Remove from group | Removes the user from a user group or organization. | Yes - adds them back. |
| Add to role | Assigns a regular role directly to the user. | Yes - removes the role. |
| Remove from role | Removes a regular role the user holds directly. | Yes - assigns it again. |
| Disable non-human identity | Deactivates a service account. Tokens issued for its OAuth 2.0 application stop working. Liferay's default service account can't be disabled. | Yes - reactivates it. |
| Revoke resource access | Removes the user's site roles on a site, then removes them from the site. Works on sites only; for an individual item, use Revoke anonymous access. | Yes - restores the membership and the site roles. |
| Revoke anonymous access | Removes everything the Guest role is allowed to do on one item. Other roles keep their permissions. | Yes - restores Guest's previous permissions, unless Guest was given new permissions on the item since. |
| Create group | Creates a user group. | Yes - deletes that group. |
| Create user | Creates a user with the given password, or a generated one (the user then sets their own with **Forgot password**). The user is created deactivated unless the request activates it. Fails if the screen name or email address is already taken. | Yes - deletes that user. |
| Delete user | Permanently deletes a user. Service accounts can't be deleted; use **Disable non-human identity**. | No - a deleted user can't be restored. |

> [!NOTE]
>
> Role actions apply to regular roles only. Site, organization, and asset library roles need a scope, so manage them in Liferay.
>
> Remove from role and Revoke resource access act on direct access only. Remove from role is refused when the user holds the role only through a site, user group, or organization. Revoke resource access is refused when the user reaches the site only through a user group or organization. Remove that assignment or membership instead. If the user has direct access and also has it through one of these, the direct access is removed, but the action reports a partial failure because access remains.

## Known limitations

* **Self-hosted and custom-domain instances need allowlisting.** Oleria reaches `*.liferay.com` and `*.lfr.cloud` out of the box. Contact [support@oleria.com](mailto:support@oleria.com) to allow any other hostname before you connect; until then, **Authenticate** fails.
* **A new address needs a new integration.** The Portal URL can't be edited after you connect. If your instance moves to a new domain, for example from self-hosted to Liferay PaaS, create a new integration.
* **OAuth 2.0 applications aren't listed.** Liferay doesn't expose its OAuth 2.0 applications through an API, so they and their secrets don't appear in Oleria. Their service accounts do.
* **MFA and SSO are instance-wide.** Liferay doesn't expose per-user MFA enrollment or SSO links, so every user shows the instance's setting.
* **Last password change comes from the audit trail.** It's shown when Liferay recorded a password change in the past year.
* **Some events aren't audited.** Sign-in and sign-out events are recorded by Liferay DXP only, and Liferay doesn't audit site membership or permission changes.
* **Inherited roles stay on the group.** A role assigned to a user group or organization appears on that group, not on each member.

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