Skip to main content
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.
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 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: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.
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:
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.
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.
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 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.