Wednesday, June 27, 2012


Liferay Portal: Services (Part Three)

I previously blogged on several improvements that could be made by Liferay in order to improve authentication and authorization. Today, I am focused on needed improvements to the security of Liferay services..

The primary way services are created in Liferay is via Liferay's ServiceBuilder utilitiy. Below are several areas of improvement that can help increase the security posture of Liferay services.

Regular Expressions
The ability to perform web-based attacks such as SQL Injection, Cross-Site Scripting, etc comes down to the desire to properly validate input. When defining new elements, there currently is no way to define what is considered acceptable values. Use of Regular Expressions (RegEx) provides a good industry standard way to sanitized input. In defining a Regular Expression, it becomes possible to have the same validation logic not only for services, but to also propagate it up to user interface validations as well.


It is important to note that with a web services paradigm, validation is not just the responsibility of the service itself. If the ecosystem also leverages intermediary devices to perform XML validation (e.g. Vordel, IBM DataPower, etc) then they may also have the need to introspect. It is very easy from the perspective of WSDL to define everything as a xsd:String but reality says that there are lots of times when the actual values are constrained.

The ability to tag a <> table as a constraint could also help propagate up to an xsd:Choice. This would not only help with validation, but also help WSDL clients develop better code.

ServiceBuilder when defining a new column does not currently allow a column to be defined as sensitive. This could be useful in scenarios where you may need to store a credit card number or other financial, health, personal identifiers. The ability to encrypt a particular column whereby the key used is specified for each company would help improve data at rest.

Liferay provides the ability to list all services registered by the Tunnel Servlet. Sometimes, you need the ability to specify when a service should not be listed.  Likewise, the level of granularity applied to listing needs to be more than just whether a service is remotely accessible or not, but to restrict listing by access method (e.g. JSON, REST, etc)

There currently is no way to constrain concurrency on particular services. For example, there is a service that allows for manipulation of the configuration for a Company (Tenant). What good reason would there ever be for hundreds of simultaneous callers?

There should be a way to tag a given service with some constraints as to how many calls can run at the same time. This is equally useful for services that consume lots of resources: either lots of I/O and/or CPU. Tagging in this manner may help prevent denial of service. Lifeway would also need to define a filter interface on the tunnel servlet to provide an enforcement mechanism related to concurrency.

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?