Using Third-Party Services for Authentication and SSO

As previously mentioned, using Liferay for authentication is not recommended for production environments. While Liferay instances begin with basic authentication, organizations should integrate with third-party authentication and SSO services. Here we'll explore some of those options available.

OpenID Connect (OIDC)

Liferay provides native support for OpenID Connect. OpenID Connect is a standards-based, decentralized authentication protocol that allows websites and applications to verify a user's identity based on existing login sessions with other services. It sits on top of OAuth 2.0, providing login and profile information in addition to the authorizations defined and handled by OAuth 2.0.

OpenID Connect is typically used in commerce scenarios, where you're allowing users to connect to Liferay using well-known providers like Google, Facebook, Microsoft, Apple, and GitHub. As long as a provider supports OIDC, you can use it for authentication with a simple configuration on the Liferay DXP side and does not require custom development. Additionally, OIDC automatically creates accounts in Liferay when users first authenticate to the platform using their OIDC credentials.

Beyond authentication, you can also map OIDC user attributes to Liferay user-scoped custom fields. When a user logs in, this mapping process automatically extracts identity data from your external provider and writes it to the corresponding Liferay user profile. You can use this mechanism to seamlessly capture specific details like a user's department, cost center, or any other custom attribute defined in your identity provider.

That said, OIDC is generally best for lightweight applications or ones that need minimum verification. From a security standpoint, you should use a more mature and feature-rich authentication standard like SAML.

SAML, SSO, and Identity Management Systems

Security Assertion Markup Language (SAML) is an alternative standard to OpenID Connect for securely exchanging authentication and authorization data between two parties. These parties are known as the identity provider (IdP) and the service provider (SP).

• Identity Provider: The identity provider is any (typically centralized) service that stores user accounts and credentials and is responsible for verifying login attempts.
• Service Provider: The service provider is any application or website that relies on the IdP to verify user identities for access control.

In this scenario, a third-party identity provider is configured to work with Liferay as the service provider. With this configuration, passwords are not maintained in Liferay, but user accounts are still created so that permissions can be assigned. This is a good example of the separation between Authentication and Authorization: Users are Authenticated against their credentials in the IDM, but are authorized by their permissions that are defined in Liferay.

SAML is frequently used to support Single Sign-On (SSO) where a single authentication task grants access to multiple systems. For example, imagine an organization that uses Liferay DXP for their intranet solution, alongside several cloud-based applications for customer relationship management (CRM), analytics, and project management. Traditionally, employees would need separate logins for the Liferay intranet and each cloud-based application. Single Sign-on allows employees to access all of these systems by authenticating once with the company's identity provider.

Keeping User Data in Sync

Liferay automatically synchronizes user data during both OIDC and SAML logins. Whenever a user authenticates, their Liferay profile updates to match the external identity provider. This approach eliminates the need for manual account creation. The system instantly applies any external changes to attributes like department, role, or group memberships. Real-time synchronization reduces administrative overhead, ensures access control stays aligned with your IdP, and delivers a seamless login experience for end users.

For scenarios requiring custom logic beyond standard synchronization, you can use the "On After Login" trigger in the User system object. Developers can use this extension point to execute additional data lookups or apply business rules. This enables you to customize the authentication experience without modifying Liferay's core authentication flow.

How to Set Up Third-Party Services

Throughout this course, we'll use basic authentication for training purposes. For detailed instructions on setting up Okta and other authentication services, official documentation:

• PingOne (SAML)
• Okta (OIDC)
• Auth0 (OIDC)