Liferay Security Best Practices: SSO, OAuth & RBAC

Introduction

Security on an enterprise portal isn't a one-and-done proposition, it is an ongoing consideration. In the case of an organization that runs on Liferay, authentication and access control isn't just best practice; it defines the experience of the organization during compliance audits, the level of protection for the organization's data, and the level of trust that the organization's teams can have when working without worrying about access rights.

It is a walkthrough of the four pillars of Liferay security, including SSO, SAML, OAuth and RBAC, including practical configuration steps, real world examples, and a compliance checklist designed for enterprise teams.

1. Liferay SSO Configuration - Centralize Authentication First

No more repeated logins, no more credential fatigue, SSO lets your users log in once and have access to what they are entitled to. For enterprises, it's also one place to set authentication policies, monitor sessions, and see what they're doing.

Liferay can serve as an Identity Provider (IdP) or as a Service Provider (SP), depending on whether you are integrating Liferay with an external IdP (such as Okta, Azure AD or PingFederate) or Liferay is your central auth system.

The following settings should be configured from the start :

• Force HTTPS : SSO should never be done over clear text.
• Set session limits : configure Session Maximum Age and Session Idle Timeout to expire stale sessions.
• Disable guest account creation if the portal is not public-facing.
• Enable MFA : SSO combined with Multi-Factor Authentication is the baseline for any sensitive portal.

Liferay supports two widely used methods to implement SSO : SAML and OIDC. Both serve the same end goal but differ in how they work and when to use them.

1.1 Liferay SAML Setup The Standard Behind Enterprise SSO

SAML (Security Assertion Markup Language) is the protocol responsible for getting SSO to work reliably between various systems and vendors. SAML has long been supported in Liferay DXP and remains fully supported in DXP 7.4 and later releases. Always configure via Control Panel → Security → SAML Admin, not the legacy Instance Settings UI.

• If Liferay is your Identity Provider (IdP) :
  • Set your Entity ID and generate your certificate + private key.
  • Enable SSL Required on all SAML messages.
  • Enable Require Authn Request Signature, every SP request must be signed.
  • Add Service Provider connections with correct attribute mappings.
  • Check the Enabled box only after everything is verified.
• If Liferay is your Service Provider (SP) :
  • Upload the IdP's metadata XML or point to its metadata URL.
  • Map IdP attributes to Liferay fields: email, name, roles.
  • Test both SP-initiated and IdP-initiated login flows before going live.
• SAML Security Checklist :

1.2 Liferay OIDC Setup - Modern SSO for Web and Mobile

OpenID Connect (OIDC) is a lightweight authentication layer built on top of OAuth 2.0. It is the more modern alternative to SAML and is especially suited for web applications, mobile clients, and scenarios where users already have accounts on external providers like Okta, Azure AD, Auth0, or Keycloak.

For OpenID Connect login scenarios, Liferay acts as an OIDC Relying Party/Service Provider and relies on an external Identity Provider such as Okta, Azure AD, Auth0, or Keycloak.

• Setting up OIDC in Liferay :
  • Go to Control Panel → Instance Settings → Security → SSO.
  • Select OpenID Connect under Virtual Instance Scope and click Enabled, then Save.
  • Go to OpenID Connect Provider tab and click Add.
  • Enter the Provider Name, Client ID, Client Secret, and all required endpoint URLs (Authorization, Token, User Info).
  • Save the configuration.
  • Test by signing out and clicking the OpenID Connect link on the Liferay login page.
• OIDC vs SAML: When to Use Which :

OIDC supports multiple providers simultaneously, you can offer users a choice of identity providers on the same Liferay login page.

2. Liferay OAuth Integration - Secure API Access Without Credential Sharing

OAuth 2.0 provides access control for third-party applications, mobile devices and APIs without revealing the user's credentials. No external system should be able to obscurely use usernames or passwords to interact with your Liferay portal; it should use OAuth.

Manage all the following from: Control Panel → Security → OAuth 2 Administration.

• Registering an OAuth App in Liferay :
  • In the OAuth 2 Administration screen, click Add (+).
  • Enter app name, website URL, and callback URIs.
  • Select the right Client Profile, this controls which authorization flows are available.
  • Define scopes, only grant what the app actually needs.
• Selecting the appropriate OAuth Flow :

• OAuth Best Practices :
  • Never grant broader scopes than what the application requires.
  • Always set access token expiry, never leave it unlimited.
  • Audit and revoke unused app authorizations regularly.
  • Use a dedicated OAuth 2 Administrator role, avoid using full admin access for token management.

3. RBAC in Liferay - Control Who Can Do What, and Where

Liferay uses Role-Based Access Control (RBAC) to control what each user can see and do. All permissions are given via roles and a poorly configured role can be a direct security hole.

Liferay's RBAC operates across three scopes :

Permissions in Liferay are additive, users only get what's explicitly granted. Nothing more.

• RBAC Best Practices :
  • Least privilege, only grant what the role genuinely needs, nothing extra.
  • Use User Groups, assign roles to groups, not individuals; it scales better and is easier to audit.
  • Split admin responsibilities, separate roles for content, user management, and system config.
  • Review roles quarterly, catch permission creep before it becomes a compliance issue.

4. Liferay Audit Logging - Visibility Is Part of Security

One part of the equation is security configuration. The other is knowing what is going on in your portal. The Liferay's Audit Framework (Enterprise) records logins, failed logins, role changes, and changes to users, and in many industries that demand regulation, this is not a choice.

• To enable audit logging :
  • Navigate to the Control Panel -> Configuration -> System Settings -> Security -> Audit section.
  • Enable the Logging Message Audit Message Processor.
  • Choose CSV or JSON format based on your SIEM or log management tool.
  • For file-based logs, configure Log4j via portal-log4j-ext.xml.

Audit logs should be retained, secured, and reviewed regularly, not just enabled and forgotten.

Enterprise Security Compliance Checklist