Service access policies are a new feature in Liferay DXP 7.0. They are an additional layer of web service security defining services or service methods that can be invoked remotely. Many of them can be applied at once to produce a combined effect. Service access policies apply only to remote services, not to local services. 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 Liferay DXP server’s 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
JavaScript using Liferay.Service(...)
. If Liferay DXP cannot associate the
caller’s authentication token with a portal 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 the appropriate Liferay DXP permissions to invoke the service.
Note that service access policies respect Liferay DXP’s permissions system. Even 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 need to access Liferay DXP’s web services. Your portal 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.
Managing Service Access Policies
To manage service access policies, navigate to Liferay DXP’s Control Panel and click on Service Access Policy under the Configuration heading. Here, you can see the default service access policies and you can 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:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz#:@-./_
-
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,com.liferay.portal.kernel.service.UserService
allows any method from the
UserService
class to be invoked.com.liferay.document.library.kernel.service.DLAppService#get*
allows any method from the
DLAppService
that starts withget
to be invoked. Thus,com.liferay.portal.kernel.service.UserService com.liferay.document.library.kernel.service.DLAppService#get*
allows any method from the
UserService
class to be invoked and any method from theDLAppService
whose name starts withget
to be invoked.
Liferay DXP contains four service access policies that are enabled by default:
- SYNC_DEFAULT
- SYNC_TOKEN
- SYSTEM_DEFAULT
- SYSTEM_USER_PASSWORD
The SYSTEM_DEFAULT
policy applies to every request, including unauthenticated
requests. Thus, its list of allowed method signatures is empty, meaning that no
Liferay DXP API can be invoked. The SYSTEM_USER_PASSWORD
policy applies to
requests for which AuthVerifierResult.isPasswordBasedAuthentication
is
true
: i.e., whenever user authentication took place using a password. Its
list of allowed method signatures is *
, meaning that any Liferay DXP API can be
invoked. Of course, since Liferay DXP API functions include permission checks, the
success of an invocation depends on whether the user has the required
permission. If you want to completely disallow certain Liferay DXP API functions
from being invoked, you can change the SYSTEM_USER_PASSWORD
policy to
something more restrictive than *
.
The SYNC_DEFAULT
policy applies to every Liferay Sync request, including
unauthenticated Sync requests. Its list of allowed method signatures includes
only the com.liferay.sync.service.SyncDLObjectService.getSyncContext
method.
The 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 Liferay DXP API function that’s a
method of a class in this package can be invoked.
SYNC_DEFAULT
and SYSTEM_DEFAULT
, as their names suggest, are default
service access policies. Default service access policies are applied to all
incoming requests, including unauthenticated requests. Administrators can
create new default service access policies. To add, edit, or delete a service
access policy, navigate to the Configuration → Service Access Policy
section of the Control Panel. Each Liferay plugin can declare own default
policy. (The SYNC_DEFAULT
policy is a good example.) This policy can then be
changed or disabled by portal administrator. 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 SYSTEM_USER_PASSWORD
service
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
instead.
Service Access Policy Module
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 forServiceAccessPolicy
.com.liferay.portal.kernel.security.service.access.policy.ServiceAccessPolicyManager
: defines the public interface for retrieving instances ofServiceAccessPolicy
.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.com.liferay.portal.kernel.security.service.access.policy.ServiceAccessPolicyThreadLocal
: makesServiceAccessPolicy
instances active.
Liferay’s Service Access Policy module resides in the
modules/apps/service-access-policy
directory in Liferay DXP’s source code. In a
running Liferay DXP instance, the service access policy functionality is provided by
these three bundles which you can find in the [Liferay Home]/osgi/modules
directory:
com.liferay.service.access.policy.api.jar
com.liferay.service.access.policy.service.jar
com.liferay.service.access.policy.web.jar
These modules provide the service access policy management UI that’s accessible
from the Control Panel. They also provide the interface and default
implementation for ServiceAccessPolicy
.
To configure the Service Access Policy module, navigate to Liferay DXP’s Control
Panel, click on System Settings, and find the Service Access Policies
module in the Foundation 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
AuthVerifier
.
Liferay DXP also contains 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.
Summary
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. The service access policies attached to an application define the services that can be invoked by the application. For example, a Sync service access policy could be created that defines all of the services that the Sync application needs to invoke. Then this service access policy could be attached to the Sync application on OAuth.
Related Topics
(Coming Soon)