Service access policies are an additional layer of web service security that define which services or service methods can be invoked remotely. As such, they affect only remote services, not local services. You can apply many of them at once to produce a combined effect. To help you understand how service access policies fit into the big picture, here’s a summary of Liferay DXP’s web service security layers:
IP permission layer: The IP address from which a web service invocation request originates must be white-listed in the portal properties file. Any attempted web service invocation coming from a non-whitelisted IP address automatically fails.
Service access policy layer: The method corresponding to a web service invocation request must be whitelisted by each service access policy that’s in effect. Wildcards can be used 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 value
of the authentication token is generated by Liferay DXP and is 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
Liferay.Service(...). If Liferay DXP cannot associate the
caller’s authentication token with a portal user, the web service invocation
User permission layer: Properly implemented web services have permission checks. The user invoking a web service must have permission to invoke the service.
Note that service access policies respect the permissions system. If a service access policy grants a user access to a remote service, the user must still have the appropriate permissions to invoke that service.
Service access policies are especially useful when remote applications such as mobile devices or Liferay Sync instances must access web services. Administrators can use service access policies to ensure that these devices can only invoke remote services from approved lists that can be modified at runtime.
Navigate to the Control Panel and click on Service Access Policy under the Configuration heading. Here, you can see the default service access policies and add new ones. When creating or editing service access policies, keep these points in mind:
Service access policy names must be unique per portal instance.
Service access policy names can include only these allowed characters:
Service access policy titles can be localized; service access policy names cannot be localized.
Allowed service signatures must be entered one per line. Wildcards (
*) are allowed for both class names and method names. The
#symbol must be used to separate a class name from a method name. For example,
allows any method from the
UserServiceclass to be invoked.
allows any method from the
DLAppServicethat starts with
getto be invoked. Thus,
allows any method from the
UserServiceclass to be invoked and any method from the
DLAppServicewhose name starts with
getto be invoked.
There are six service access policies that are enabled by default:
ASSET_ENTRY_DEFAULT allows the view counter for assets to be updated when an
asset is retrieved.
CALENDAR_DEFAULT makes it possible to search public events
in the calendar. The
SYSTEM_DEFAULT policy applies to every request, including
unauthenticated requests. It allows access to country/region services by
SYSTEM_USER_PASSWORD policy applies to requests for which
true: i.e., whenever
user authentication took place using a password. Its list of allowed method
*, meaning that any API can be invoked. Of course, since API
functions include permission checks, this call works only if the user has the
required permission. If you want to completely disallow certain API functions
from being invoked, you can change the
SYSTEM_USER_PASSWORD policy to
something more restrictive than
SYNC_DEFAULT policy applies to every Liferay Sync request, including
unauthenticated Sync requests. Its list of allowed method signatures includes
SYNC_TOKEN policy applies to Sync requests which are accompanied by an
authentication token. Its list of allowed signatures includes
com.liferay.sync.service.*, meaning that any API function that’s a
method of a class in this package can be invoked.
SYSTEM_DEFAULT, as their names suggest, are default
service access policies. Default service access policies are applied to all
incoming requests, including unauthenticated requests.
You can create new default service access policies:
Navigate to the Configuration → Service Access Policy section of the Control Panel.
Click Add ().
Flip the switch to enable your policy.
If you want the policy applied to unauthenticated requests as well as authenticated requests, flip the switch labeled Default.
Give your policy a title.
Under Allowed Service Signatures, start typing the fully qualified name of a service class that’s installed. Code completion helps you find the class. For example, if you’re creating a policy for Liferay’s Knowledge Base application, you could enter
Under Method Name, start typing a service method call. Again, code completion helps you. For Knowledge Base, you could enter
To specify another service or method, click the plus icon to add another entry.
When done, click Save.
Liferay applications can declare their own default policies (the
policy is a good example). This policy can then be changed or disabled by
administrators. In this case, the plugin can still verify that the policy exists
so there is no need to redefine or update it.
By default, Liferay’s tunneling servlet uses the
access policy. You can, however, create your own policy for the tunneling
servlet and use the property
service.access.policy.name for the
TunnelingServletAuthVerifier to specify that your policy should be used
Liferay’s service access policy functionality is provided by the Service Access Policy module. This module includes the following important classes:
com.liferay.portal.kernel.security.service.access.policy.ServiceAccessPolicy: defines the public interface for
com.liferay.portal.kernel.security.service.access.policy.ServiceAccessPolicyManager: defines the public interface for retrieving instances of
com.liferay.portal.kernel.security.service.access.policy.ServiceAccessPolicyManagerUtil: bridges service access policy functionality to the parts of Liferay’s core that have not yet been modularized.
Liferay’s Service Access Policy module resides in the
modules/apps/service-access-policy folder in the source code. When running,
these three bundles provide the service access policy functionality (they’re in
[Liferay Home]/osgi/modules folder):
These modules provide the service access policy management UI that’s accessible
from the Control Panel. They also provide the interface and default
To configure the Service Access Policy module, navigate to the Control Panel,
click on System Settings, and find the Service Access Policies module in the
Security section. Click on its name to edit it. Here, you can edit the default
service access policy configuration. You can also force a default policy to be
applied even when no policies are applied by the
There’s also an
AuthenticatedAccessControlPolicy. This policy doesn’t do
anything if a
ServiceAccessPolicyManager implementation is present. If the
service access policy module is disabled, however, the
AuthenticatedAccessControlPolicy provides a fallback that still requires
authenticated access for web services.
Great! Now you know service access policies can restrict access to Liferay DXP’s web services. Custom service access policies can be created by portal administrators. They are applied by the portal’s token authenticator, e.g., by OAuth.