Friday, August 10, 2012

Auditing in JBoss Enterprise Portal Platform (EPP)

One of our Red Hat JBoss Enterprise Portal Platform (EPP) customers recently had a requirement to audit all access to their EPP environment. The requirements were:
  1. Audit which users login to the portal, and at what time.
  2. Audit which portlets are being accessed by the user.

The first requirement was implemented by utilising the auditing functionality of the JBoss Security framework. As JBoss EPP is based on JBoss Enterprise Application Platform (EAP), auditing can be implemented in the same way as explained in this blog-post by my colleague Anil Saldhana: Furthermore, due to the fact that this security auditing framework is easily extendible, security auditing can be tailored to one's specific needs. In fact, in the current project we implemented a customised version of the JBoss Security AuditProvider interface to reduce the verbosity of the auditing and to log the audit information to a back-end system instead of the default Log4J log-file.

The second requirement can however not be implemented using the Security Auditing framework. Although the framework is able to log which URLs are accessed by the user, it is unable to provide more detailed information on which portlets are actually being accessed. Luckily, the JSR-286 Portlet Specification introduced so called Portlet Filters. Portlet Filters allow one to intercept and filter individual PortletRequests, and as such provide a good entry-point for auditing portlet requests. Furthermore, the JBoss Enterprise Portal Platform allows one to configure systemwide portlet filter-chains, i.e. filter-chains that will be applied to all portlets deployed on the platform, via the {jboss-epp}/jboss-as/server/{profile}/conf/gatein/portlet.xml configuration file. This allows us to control the auditing of portlets from a single point within the system.

The JBoss EPP PortletAuditFilter project provides a first implementation of a simple auditing component for JBoss EPP, that can audit which users access which portlets, including the lifecycle method being called. The current implementation is still limited, as it only provides a filter that will log the audit information to a Log4J log-file. However, the component has been designed to be extended. By extending from AbstractPortletAuditingFilter, and implementing the getLogger() AbstractFactoryMethod, you can provide your own AuditLogger implementation. This allows you to, for example, log the audit information in a database, a data-grid, or any other form of storage. The Log4JPortletAuditingFilter provides a nice starting point for your own custom implementation.

Please consult the README.txt file for installation and configuration instructions.

Although this is a very basic tool, it satisfies our current portlet auditing requirement. Possible future improvements might include filters to whitelist or blacklist auditing information for specific portlets in order to give the user more control over the verbosity of the audit logging.