Securing Web Services
Liferay DXP provides four security layers for web services:
IP permission layer: The IP address from which a web service invocation request originates must be white-listed in the portal properties file. A web service invocation coming from a non-whitelisted IP address automatically fails.
Service access policy layer: Methods corresponding to a web service invocation request must be whitelisted by each service access policy that’s in effect. You can use wildcards to reduce the number of service classes and methods that must be explicitly whitelisted.
Authentication/verification layer (browser-only): If a web service invocation request comes from a browser, the request must include an authentication token. This authentication token is the value of the p_auth URL parameter. The token is generated by Liferay DXP and associated with your browser session. The p_auth parameter is automatically supplied when you invoke a Liferay DXP web service via the JSON web services API page or via JavaScript using Liferay.Service(...). If Liferay DXP cannot associate the caller’s authentication token with a User, the web service invocation request fails.
User permission layer: Properly implemented web services have permission checks. The user invoking a web service must have permission to invoke the service.
Authorization
Liferay DXP contains several adjustable authorization layers:
- Remote IP and HTTPS transport check to limit access to Liferay DXP’s Java servlets
- Extensible Access Control Policies layer to perform portal service-related authorization checks
- Extensible Role-based permission framework for Liferay assets (stored in the database or elsewhere)
- Portlet container security checks that control portlet access
- Remote IP check for remote API authentication methods
- Service Access Policies to control access to remote APIs
- Authentication Verifiers that verify provided credentials.
- Cross-Origin Resource Sharing configuration can enable retrieving resources from trusted sources only.