Building a Single Sign-On Module for the BIRT Report Viewer – Part 3-2

This is the fourth (actually second part of the third) post of the BIRT SSO Series wherein I describe the implementation of a single sign-on module for the Eclipse BIRT Report Viewer. The introduction and server configuration are covered in Part 1 and Part 2 respectively. The Drupal Module component follows in Part 3-1. It is recommended that you read them first in order to get acquainted with the background and the premises on which this solution is built. In this post, I describe the BIRT Module.

3.2: The BIRT Module

In Part 3-1, I described how the Drupal Module encrypts a string of information and sends it over to the BIRT component. Once the BIRT Module has received this encrypted data, it needs to decrypt and process the string to provide or revoke authentication for a particular user. There are 4 classes that are involved in orchestrating this process:

  1. AuthFilter: An instance of javax.servlet.Filter that intercepts all incoming requests to BIRT’s servlets and allows or rejects them based on session authentication.
  2. AuthManagerServlet: A subclass of javax.servlet.http.HttpServlet that receives and processes incoming authentication requests from the Drupal Module.
  3. SessionLifecycleListener: An instance of javax.servlet.http.HttpSessionListener that listens for session events generated by client-connects and session timeouts, and does some voodoo.
  4. Transcoder: A simple utility class that provides methods for decryption and checksums.

Before I get into the nitty-gritties of the individual classes, a little explanation of the overall flow is needed. Briefly, here’s what transpires:

  1. AuthManagerServlet receives an encrypted request. It attempts to decrypt it using Transcoder‘s utility methods. If successful, the following parameters now become available to it:

    1. A universally unique session id (session created by Drupal).
    2. A flag denoting whether this is a login or a logout operation.
    3. A timeout which can be set for a newly created session (in case of a login).
  2. In case this is a login operation, this session id is stored in a map (as the key, with NULL for value).

    1. Every request coming in from the client’s browser will contain a cookie with this session id.
    2. This request has come in directly from the Drupal server, so the session created on the Java side for this request does not map to the actual client browser.
  3. When the client sends its first request to the reporting component, a new Java session is created for it, and the session map is updated with the session id of this session. So now we have a Drupal session mapped to a Java session, cookies for both being stored in the client browser. The timeout value is also set, at this point, for the newly created Java session.

  4. All further requests coming in from the client are validated for the correct Drupal and Java session ids.
  5. If the original encrypted request was a logout operation, then the appropriate entry is removed from the session map.
  6. A session map entry can also be removed if triggered by a session timeout.
    Now that we have the flow in mind, let’s dive right into the code. With the background knowledge given above, the logic should be fairly easy to follow. Finally a few entries go into web.xml to tie it all together: That concludes this series on implementing an SSO for the Birt Report Viewer. Hope it helps you build your own custom implementation. If you have any questions, observations or suggestions, just leave a comment and I’ll answer as best as I can.