Liferay DXP includes a centralized and extensible authentication layer called the authentication verification layer. This layer is mainly used for authenticating remote invocations of Liferay DXP’s API.
The main responsibilities of the authentication verification layer are to
- Verify provided credentials using registered
- Create portal authorization contexts based on verification results
If no available
AuthVerifier is able to verify request credentials, an
authorization context supporting non-authenticated access is created for a
guest user. This allows each Liferay DXP API to expose only a single API endpoint.
In contrast, legacy (prior to 6.2) versions of Liferay DXP exposed two API
endpoints for each API: the
/api/endpoint URI was for non-authenticated
access and the URI
/api/secure/endpoint was for authenticated access.
Liferay DXP offers built-in
AuthVerifier implementations for the most common
situations. These include situations where remote clients use HTTP Basic or
HTTP Digest authentication, send credentials in request parameters, send
JSESSIONIDs, or use shared secrets to establish trust. Other
AuthVerifier implementations can be deployed as modules containing
implementations of the
AuthVerifier interface that are registered as services
in Liferay DXP’s OSGi runtime.
Note: The authentication verification layer’s focus is on verifying authentication, not on providing credentials. The authentication verification layer is NOT responsible for issuing tokens, credentials, or displaying Sign In portlets. Instead, the layer verifies existing credentials and authenticated sessions and is therefore a complement to authentication endpoints. However, to ensure backwards compatibility, the default portal implementations support requests providing username and password credentials. Thus, the authentication verification layer stands on the border between authentication and authorization.
This layer and surrounding processes are provided by the
class that implements the
Step 1: Verify Request Credentials
The layer uses the chain of responsibility design pattern to support both
built-in and third party
AuthVerifier implementations. Each
can provide configurations where it specifies mapped URLs and other properties.
Each incoming request is matched against all registered
select the final list of
AuthVerifiers that is used to process the request.
It’s the responsibility of each
AuthVerifier to verify the incoming request
Step 2: Create an Authorization Context
When a request is processed by all matching
AuthVerifiers, Liferay DXP creates an
authorization context for the resolved user.
This encompasses setting the
remoteUser to return the
resolved user ID setting Liferay DXP
ThreadLocals to the resolved user.
The resolved user can be the user returned by one of the
instances or a guest user if no instance was able to verify the provided
For more detailed technical information, please see the AuthVerifiers (not yet written) tutorial.