Service Security Layers

By default, a user connecting from the same machine Liferay is running on can access remote services so long as that user has permission to use those services in Liferay’s permissions system. Of course, you are not really “remote” unless you are accessing services from a different machine; but we recommend using the API in a remote manner to trigger the security checks. Liferay has two layers of security when it comes to accessing its services remotely. The first layer of security only applies to clients invoking the API using a remote protocol. Invoking the API using a remote protocol, without having explicit rights to both layers, results in a remote exception being thrown and access being denied to those services. However, if you want to invoke the API using Java invocation, skip to the the paragraph that refers to the second layer of security.

The first layer of security a client needs to get through to call a method from the service layer is invoker IP filtering. For example, you may have a batch job which runs on another machine in your network. This job looks in a particular shared folder on your network and uploads documents to your site’s Documents and Media portlet on a regular basis, using Liferay’s web services. To enable this batch job to get through the IP filter, the portal administrator will need to set portal properties appropriately to allow the machine access to that particular type of service. For example, if the batch job uses the Axis web services to upload the documents, the portal administrator would need to add the IP address of the machine on which the batch job is running to the axis.servlet.hosts.allowed property. A typical entry might look like this:

axis.servlet.hosts.allowed=192.168.100.100, 127.0.0.1, SERVER_IP

If the IP address of the machine on which the batch job is running is listed with allowable hosts for the service, then that machine is allowed to connect to Liferay’s web services, pass in the appropriate user credentials, and upload the documents.

Figure 8.1: Liferay SOA’s first layer of security

Note: The portal.properties file resides on the portal host machine and is controlled by the portal administrator. Portal administrators can configure security settings for the Axis Servlet, the Liferay Tunnel Servlet, the Spring Remoting Servlet, the JSON Servlet, the JSON Web Service Servlet, and the WebDAV Servlet. The Properties Reference chapter of Using Liferay Portal describes these properties.

The second layer of security is Liferay’s security model that it uses for every object in the portal. The user ID that accesses the services remotely must have the proper permission to operate on the objects it will be accessing. Otherwise, a remote exception will be thrown. The Portal Administrator will need to make use of Liferay’s usual means of granting users access to these resources. For example, say a Documents and Media Library folder called Documents has been set up in a site and a role has been created called Document Uploaders which has the rights to add documents to this folder. Your batch job will be accessing Liferay’s web services to upload documents into this folder. In order for this to work, you will have to call the web service using the user ID of a user who is a member of this group (or the user ID of a user with individual rights to add documents to this folder). Otherwise, the user will be prevented from using the Web Service.

Figure 8.2: Liferay SOA’s second layer of security

The remote services allow specifying the user credentials using HTTP Basic authentication. Since those credentials are specified unencrypted, it is recommended to use HTTPS whenever accessing these services from or through an untrusted network. Most HTTP clients allow specifying the basic authentication credentials in the URL which is very handy when doing tests.

To call the AXIS web service using credentials, you would use the following URL syntax:

http://" + userIdAsString + ":" + password + "@[server.com]:[port]/api/secure/axis/" + serviceName

The user ID is the user’s ID from the Liferay database. This may be obtained by logging in as the user and navigating to the My Account page of the control panel. On this page, the user ID appears below the user’s profile picture and above the birthday field.

For example, to get Organization data using a user with the ID of 2 and a password of test, you would use the following URL:

http://2:test@localhost:8080/api/secure/axis/Portal_OrganizationService

Note: In old Liferay versions you could access those services by using http://localhost:8080/tunnel-web/axis. However, this path has changed in Liferay 6.1. When you enter it, you’re redirected to the new one.

The authorization type specified for your portal’s company dictates the authorization type you must use to access your web service. The portal administrator can set the security authentication type to either of the following:

• screen name
• user ID
• email address

It is important to note here how Password Policies (see chapter Management of Using Liferay Portal) can be used in combination with this feature. If the portal is enforcing password policies on its users (requiring them to change their passwords on a periodic basis, etc.), any administrative ID which accesses Liferay’s web services in a batch job will have its password expire too.

To prevent this from happening, the portal administrator can add a new password policy which does not enforce the password expiration and add your administrative user ID to it. Then your batch job can run as many times as you need it to, and the administrative ID’s password will never expire.

In summary, accessing Liferay remotely requires the successful passing of two security checks:

1. The IP address must be pre-configured in the server’s portal properties.

2. The user must have permission to access the related resources.

Next, we’ll learn about Liferay’s SOAP web services.