Overview#

Some customers use a Web Access Management infrastructure to get an additional level of protection for their Liferay installations. Examples of products that can be used for this purpose are CA SiteMinder, maXecurity from P2 Security or Nevis from Adnovum.

The principle is to protect URLs that a user wants to access on the Liferay server one layer before. This approach can be used very well for traditional static pages, as every page or functionality has a unique URL. But we will show that the approach to protect modern portal servers by URLs has its limits.

Modern portal servers like Liferay offer powerfull features like role based content and applications (portlets). The menu of the portal is dynamically controlled by the users roles. I.e. a "Guest" only sees a subset of the menu, a "User" sees additional portlets and only a "Power User" can see the full menu. Roles are used heavily (> 20) in Liferay installations to model the real world requirements. But roles do not only control the menu structure. It is also possible to add more portlets with different required roles to the same page (accessed by one URL). The "Guest" may only see the "Welcome Portlet", the "User" may see an additional portlet and so on. It is important to understand that these powerfull features go far beyond the traditional approach of static pages.

Examples#

The communication of portlets is depending on the used technologies. These technologies are changing. A migration of JSF 1.2 to JSF 2.0 in the near future will change this communication paths!

To try out for Icefaces and Richfaces:

• Install Liferay 5.2.3
• Open the Control Panel
• Open Portlet "Plugin Installation"
• Install "Sample ICEfaces JSF 1.2 (Sun Facelets)"
• Install "Sample Richfaces JSF 1.2 Sun Facelets"
• Place the portlets on a page and take a look at tools like Firebug

Richfaces Portlet JSF 1.2#

Portlet is located on home page /web/guest/home

• Access by /web/guest/home
• Pressing a button in the portlet: POST /web/guest/home?p_p_id=1_WAR_richfacessunjsf12faceletsportlet_INSTANCE_PIi5&_1_WAR_richfacessunjsf12faceletsportlet_INSTANCE_PIi5__jsfBridgeViewId=%2Fpages%2Fview.xhtml

Direct access to the JSF pages is forbidden by security congif in web.xml

<security-constraint>
		<web-resource-collection>
			<web-resource-name>Page Sources</web-resource-name>
			<url-pattern>*.jsp</url-pattern>
			<url-pattern>*.jspx</url-pattern>
			<url-pattern>*.xhtml</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>nobody</role-name>
		</auth-constraint>
	</security-constraint>
	<security-role>
		<role-name>nobody</role-name>
	</security-role>

Icefaces JSF 1.2#

• Access by /web/guest/home
• Pressing a button in the portlet: POST /sample-icefaces-jsf-1.2-sun-facelets-portlet/block/send-receive-updates

If more portlets are bundled in the same WAR (this is the default case) all portlets POST to the same URL WAR_NAME/block/send-receive-updates.

Direct access to the JSF pages is forbidden by security congif in web.xml

<security-constraint>
		<web-resource-collection>
			<web-resource-name>Page Sources</web-resource-name>
			<url-pattern>*.jsp</url-pattern>
			<url-pattern>*.jspx</url-pattern>
			<url-pattern>*.xhtml</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>nobody</role-name>
		</auth-constraint>
	</security-constraint>
	<security-role>
		<role-name>nobody</role-name>
	</security-role>

Struts 1.0#

Struts 1.0 is used by all Liferay portlets.

• Access by /web/guest/home
• Pressing a button in the portlet: POST to /web/guest/home?p_p_id=24...

p_p_id is the id of the portlet.

Direct access to the portlets JSPs is forbidden by Struts architecture.

Packaging of portlets #

Typically all portlets related to one business topic are bundled as an JEE web application (the war file). I.e. a banking solution is bundled in one war file with 25 portlets. This packaging has dramatic consequences to the application design.

Session#

All portlets inside one WAR share the same HTTP session. This makes passing parameters between the portlets easy. Also features like Inter Portlet Communication (updating values in more than one portlet) are depending on a common session.

Classloader#

If portlets of different WAR have to communicate the situation gets complicated: the applications have different class loaders. This means that even if the two portlets use the same Java class communication by this class is not possible as the classes have different class loaders. This means that all communication has to be done by basic types (HashMaps with Strings, XML).

Libraries#

Libraries are stored in the WEB-INF/lib folder of each WAR file. Typically the size of the used libraries is about 10 MB or above. If we need some report features this can rise to 20 or 30 MB. If we divide a WAR in more WARs these libraries have to be copied every time. The problem here is that all classes are stored in the "Perm Space" of the Java VM. This space has about 180 MB for a naked Liferay installation. The Perm Space can not be used by the application itself, but the occupied space is missing in the important "Heap Space". Also the startup times will rise depending on the size of the deployment units. A full deployment of a typicall Liferay instance today has > 100 MB. If you decide to duplicate some libraries you can end up with some 100 MB.

Common Problems#

Portlet URL#

In traditional Web Applications the application is identified by the URL. I.e. by typing in the URL myhost/war-name/FirstPage.xhtml you can access the start page of an application. This is not true in portal environments. Here the portlet is embedded in the portal and is displayed in an URL of the portal. Accessing the application by it's URL is typically not possible.

More portlets on one page#

If more than one portlet is used on one page and the portlets require different roles all portlets share the same URL. Thus it is impossible to protect access to these portles based on the single roles. It is just possible to protect the access to all portlets.

Portlets with different roles#

If you want to protect you URLs with WAM tools you have to divide your portlets in different WARs.

Page with different roles#

If you use a page and configure it's content to require different roles you can only protect by the "weakest" role. If you have content for role "Power user" and content for "User" on one page you can protect the URL for this page for role "User". But this requires that your roles are defined hierarchical (like "User" is a subset of "Power User").

Ajax communication #

In Icefaces or all JSF 2.0 implementations the communication of the portlet is done with AJAX. This results in a generic path for all POST request of portlets in one WAR. It is not possible to filter request for one special portlet.

Use cases#

Ensure in WAM that only special roles can access a portal page#

Possible by protecting the URL of the portal page. But be careful: Liferay supports some concepts of URL Rewriting like "Friendly URLs" or Virtual Hosting that have to be considered.

Ensure in WAM that only special roles can access a portlet#

• Protect the page where to portlet is placed. This is only possible if all other portlets on this page share the same role.
• Depending on the HTTP communication of the portlet: protect the postback URL. This is typically only possible if all portlets with the same role are bundled in the same WAR.