This is the first post of a series in which I attempt to lay down a scheme for integrated authentication (or single sign-on) between the Eclipse BIRT Report Viewer and some other independent web application.
Part 1: Introduction
The Eclipse BIRT project has long been one of the best open source alternatives for anyone looking to hook up a powerful web-based reporting component to drive their business analytics (Here’s a useful comparison matrix for other open source reporting platforms).
There are several integration points available that you can use to tie in the reporting engine to your existing applications. Arguably the easiest way to do it, is to just deploy the BIRT Report Viewer webapp onto a server like Tomcat or Jetty. The application is best described on the website itself (http://www.eclipse.org/birt/deploy/#viewer):
The BIRT Viewer can be used in a variety of ways:
- As a stand-alone, pre-built web application for running and viewing reports.
- As a starter web application that you can customize to your needs.
- As an example for learning how to build your own reporting web application, or to learn how to use the BIRT engine.
- As a way to run a report using a URL. This option provides a simple way to integrate BIRT reporting into applications build using non-Java technology such as Perl, PHP or even static web pages.
The BIRT viewer is a web application included with BIRT to perform the report preview operation within Eclipse. It is also a sample of how to integrate birt with a web application.
The webapp is fully functional and capable of running any BIRT report, including drill-downs, sub-reports and interactive charts. It also supports runtime parameter entry through a nice AJAX interface. There are built-in handlers for exporting the rendered report or the raw data into various formats, including, but not limited to PDF, DOC and XLS. There’s also support for client-side and server-side printing, pagination and TOC. The interactive portions of the UI are fully AJAX-driven.
Being this feature-rich means there is usually little to no functional enhancement required, for the application to be usable in a production environment right out of the box. Not bad for a “sample” app!
The only thing it lacks is application-managed authentication. I see this as an advantageous omission, since the developer (or system integrator) would actually need the flexibility to decide upon or design the authentication mechanism to use, depending on which other system(s) this reporting app is being integrated with. More often than not, one would look for a single sign-on solution that lets users seamlessly switch between the reporting context and any other business context that the application ecosystem provides.
Outlined in this series of posts is one such scheme that I designed for a hybrid system comprising a PHP application providing the most of the functionality (including the user management) and the BIRT Report Viewer as the reporting component. Users would login through the PHP application, and this step would serve to authenticate them to the report server as well.
DISCLAIMER: I do not claim to be a web security expert, and there could be (and probably are) vulnerabilities in the scheme that I describe hereon. If you’re planning to use this scheme for your own deployment, please take care to thoroughly examine it first for any security holes. I am not responsible if your decision to adopt my method leaves your system(s) vulnerable to attack. If you do find something that ought to be rectified, please leave a comment describing the problem, and if possible, a solution.
Now that we’ve got the niceties out of the way, on to the details – starting with a description of the specific ecosystem for which this scheme was originally designed:
- A Drupal (PHP-based CMS) application running on an Apache 2.2 server, say at http://yourdomain.com.
- This is the only application in the hybrid system which has access to (persistent) user data, and is the primary site through which users log in.
- Upon login, this application sets a cookie in the user’s browser which will later be required by the report server as well. This places a restriction on where (URL) the report server can be located. It can either be at http://yourdomain.com/<report root> or at http://<report root>.yourdomain.com[:port]. In the latter case, the cookie domain must be set to .yourdomain.com in order for the cookie to be valid for both the top level domain and subdomain. (CAUTION: This makes the cookie valid for ANY subdomain under yourdomain.com, meaning the browser will send it across for any request made to any URL of the form <subdomain>.yourdomain.com[:port]/*, including possibly those which should not be privy to it.)
- The BIRT Report Viewer running on Apache Tomcat 7.0.
- In my case the report component was accessible at http://yourdomain.com/<report root>. This needs the Apache-Tomcat connector module (mod_jk) to be enabled. The configuration is explained later.
- The report viewer does not have direct access to the user master data. Instead it relies on server-to-server communication, taking place in the backend when a user logs in, for authentication data. This data is stored in memory for the lifetime of the session, which can be expired by either a session timeout, a user logout event, or a server (Tomcat) shutdown.
That’s it for the introduction. Part 2 of this series delves into the details of the server configuration.