Monitoring Sun Java System Access Manager Activities with Actuate Enterprise Reporting Platform: An Integration Story

Print-friendly Version

Standards-based Sun Java System Access Manager 2003Q4 (called Access Manager for short) is a security foundation with which enterprises can manage secure access to Web applications, both within the enterprise itself and across businesses. Access Manager provides open, standards-based authentication and policy-based authorization with a single, unified framework. As organizations require more financial, organizational, and commercial agility to compete, Access Manager does the following to meet their needs:

• Provides scalable access-management services that safeguard data delivery and improve user experience through Single Sign-On (SSO)
  
  
• Delivers a federated identity framework to create revenue opportunities through enhanced affinities with partners and customers

Actuate 7 is the only unified platform in the marketplace today for developing and deploying enterprise reporting applications that present decision-making information with easy-to-use interfaces, personalized relevance, and timely delivery. The result is adoption by an overwhelming majority of users. In addition, Actuate 7 offers these two capabilities:

• A flexible development architecture that meets user requirements for intuitively accessible and personalized data.
  
  
• A scalable deployment architecture that serves all.

The Actuate Enterprise Reporting platform consists of two major components:

• Actuate iServer -- This is a scalable, cluster-enabled enterprise server for generating, managing, and securely delivering reporting and analytic content to users within an enterprise. Actuate iServer provides a complete infrastructure for acquiring data from the underlying data sources and disseminating interactive, actionable business information to end-users in a variety of forms and formats--Dynamic HTML (DHTML), XML, spreadsheet, PDF, Online Analytical Processing (OLAP) cubes. In addition, Actuate iServer exposes a Web services API that covers all of the Actuate iServer functionality and enables complete automation through programmability.
  
  
• Actuate Active Portal -- This is the main, standards-based Actuate end-user product: a Web application that you can deploy under J2EE platform-compliant Web containers. It serves as an HTTP front end for Actuate iServer. Actuate Active Portal, easily customizable by virtue of the Struts framework and tag libraries, enables organizations to seamlessly integrate reporting content into their sites. All communications with Actuate iServer, which are SOAP-based, are effected through the Actuate Web services API.

This paper describes the procedure for integrating Actuate 7 with Access Manager so as to generate reports that reflect the activities on Access Manager. Also discussed are enhancements and workarounds for known bugs.

This integration takes advantage of the reporting capabilities of the Actuate suite to generate dynamic reports for monitoring or auditing activities on Access Manager. The reporting utility is integrated within the Access Manager Administration Console, from which you can create and view reports.

Actuate iServer and Actuate Active Portal reside on the same machine as Access Manager. Actuate's e.Report Designer models and creates Actuate report designs (.rod), which it then compiles and publishes to Actuate iServer as executable files (.rox). Finally, you invoke the executables with the required parameters to generate reports.

TABLE 1 lists three example reports that are based on the log files created in Access Manager, along with the associated design and executable files.

TABLE 1 Example Reports and Their Corresponding Design and Executable Files

Note - e.Report Designer generates the reports according to the logs at /var/opt/SUNWps/logs. The default flat-file format is the W3C Extended Log Format (ELF). Access Manager also contains a debug directory with logs that offer troubleshooting clues; these logs do not play a part in this integration. For more information on the log files, see Chapter 10, "Auditing Features," in the Access Manager Customization and API Guide.

Following are the hardware and software requirements for this integration:

• Solaris 9 Operating System on a SPARC machine
• Microsoft Windows 2000, XP, or NT on an x86 machine
• Sun Java System Access Manager 2003Q4
• Sun Java System Application Server Standard Edition 7.0, Update 1
• Sun Java System Directory Server 2003Q4
• Sun Java System Access Manager Policy Agent 2.1 for Sun Java System Application Server 7.0
• Actuate iServer 7, SP2
• Actuate Active Portal 7, SP2
• Actuate e.Report Designer 7, SP2

Note - To download Access Manager, Application Server, and Directory Server, go to Get the Software for Sun Java Enterprise System 2003Q4. See the first item in the table. The bundle includes those three products. For Policy Agent, go to its download page.

This section describes the three example reports in detail.

The Administrative Activity Report monitors administrator-initiated changes on Access Manager. This report is based on two log files: amAdmin.access and amAdmin.error.

FIGURE 1 shows the Actuate report design (.rod) when viewed from e.Report Designer.

FIGURE 1: Actuate Report Design for the Administrative Activity Report

TABLE 2 shows the input parameters for the executable.

TABLE 2 Input Parameters for the Administrative Activity Report Executable

FIGURE 2 shows the Administrative Activity Report as viewed from the Access Manager Console.

FIGURE 2: Administrative Activity Report (Access Manager View)

The Intrusion Activity Report identifies events that are related to user authentication and analyzes intrusions. In addition, this report details the following:

• The number of successful logins and failures in a given time frame on a per-day basis. By clicking the date, you can view that data at a glance. You can further drill down into the hourly statistics by browsing the design document Hourly Intrusion Activity Report.rod.
  
  
• The IP addresses of the users with the most successful logins and the most failures

This report is based on two log files: amAuthentication.access and amAuthentication.error.

FIGURE 3 shows the Actuate report design (.rod) when viewed from e.Report Designer.

FIGURE 3: Actuate Report Design for the Intrusion Activity Report

TABLE 3 shows the input parameters for the executable.

TABLE 3 Input Parameters for the Intrusion Activity Report Executable

FIGURE 4 shows the Intrusion Activity Report as viewed from the Access Manager Administration Console.

FIGURE 4: Intrusion Activity Report (Access Manager View)

The Resource Access Report shows data that are based on the policy evaluations recorded on Access Manager. Other statistics in this report reflect the number of policies created or modified and the most accessed resources within the time frame of the report context.

This report is based on two log files: amPolicy.access and amPolicy.error.

FIGURE 5 shows the Actuate report design (.rod) when viewed from e.Report Designer.

FIGURE 5: Actuate Report Design for the Resource Access Report

TABLE 4 shows the input parameters for the executable.

TABLE 4 Input Parameters for the Resource Access Report Executable

FIGURE 6 shows the Resource Access Report as viewed from the Access Manager Administration Console.

FIGURE 6: Resource Access Report (Access Manager View)

As the above examples demonstrate, this integration has added reporting capabilities to the Access Manager Administration Console, which is based on the Sun Java Studio Web Application Framework (called Web Application Framework for short; that product was previously known as Sun ONE Application Framework or JATO). By taking advantage of the Web Application Framework capabilities, the Administration Console offers a pluggable, easily customizable architecture.

For details on customizing the Administration Console, see Chapter 2 in the Access Manager Customization and API Guide.

Web Application Framework eases the process of developing large-scale Web applications and renders them scalable, secure, and maintainable. Based on the Java 2 Platform, Enterprise Edition (J2EE platform), Web Application Framework is geared toward development of enterprise applications.

Web Application Framework unites familiar concepts, such as display fields, application events, component hierarchies, and a page-centric development approach. It also boasts a robust design that's based on the Model-View-Controller and Service-to-Workers patterns.

TABLE 5 shows the files for integrating the Administration Console.

TABLE 5 Files for Integrating the Administration Console

In the examples, the Report tab is visible to the top-level administrator only. This restriction is made possible by the UMReportTabListener class, which verifies whether the user belongs to the topleveladmin role.

When the top-level administrator clicks the Report tab, UMAdminTabNavViewBean for the Administrative Activity Report opens, displaying the three report links along with the filter control for that report.

The source for the report content is derived from the amAdminModuleMsgs.properties file, which you revise during installation according to the content in the report.properties file. Those revisions enable further customization and localization.

The architecture for the integration assumes the following:

• Access Manager, Actuate iServer, and Actuate Active Portal reside in the same machine.
  
  
• The reports support identity log files in flat-file format, but not those in a database.
  
  
• The deployment uses the default ports for Actuate iServer and Actuate Active Portal.

For workarounds for some of the above requirements, see Troubleshooting Tips.

FIGURE 7 is a logical representation of the reporting system for Access Manager. Note that Access Manager, Actuate iServer, and Actuate Active Portal are on the same machine.

FIGURE 7: Logical Architecture of Actuate Reporting Integration with Access Manager

An SSO mechanism between Actuate Active Portal and Access Manager ensures a tightly coupled integration, whereby Actuate Active Portal accepts Access Manager's SSO token (SSOToken) for authentication and authorization.

Recall that, thanks to Web Application Framework, the reports are also available as part of the Access Manager Administration Console. Toward that end, we created an additional Report tab as part of the setup for requesting reports on the basis of the custom filters.

FIGURE 8 illustrates the physical architecture of the integration.

FIGURE 8: Physical Architecture of Actuate Reporting Integration with Access Manager

The first step toward integration is to configure SSO between Actuate iServer and Access Manager. Do the following:

1. Install Actuate iServer on the Solaris 9 (or later) Operating System.



2. In the default volume, create a couple of users, for example, xyz and abc, and test their authentication from the Actuate Management Console.
   
   
3. Select Open Security and load the modified shared library (librsse.so).



4. Deploy Actuate Active Portal on a Web container on Sun Java System Application Server 7.0, Update 1 by editing the SECURITY_MANAGER_CLASS entry in the web.xml file to point to the new class com.actuate.reportcast.security.SecurityMgr.



5. Copy the SecurityMgr.jar file to Actuate Active Portal's deployment directory.


For example, if the deployment directory is /ActivePortal, place that file in the directory /ActivePortal/WEB-INF/lib.


6. Copy the login.jsp and logout.jsp files to the /ActivePortal/private directory.



7. Change the action logout path in the /ActivePortal/WEB-INF/struts-config.xml file to the following:
   
   

   <!-- Process a user logout --> <action path="/logout" type="ISAcLogoutAction"> <forward name="logoutIS" path="/private/logout.jsp" /> <forward name="login" path="/login.do" redirect="true" /> </action>



8. Copy the ISAcLogoutAction.class file to the /ActivePortal/WEB-INF/ classes directory.



9. Install Access Manager 2003Q4 on the same machine but on a different instance of the application server.



10. Install Sun Java System Access Manager Policy Agent for Application Server to protect Actuate Active Portal.



11. Create two users, xyz and abc, that correspond to the two Actuate users created in step 2, on Access Manager.



12. From the Access Manager Administration Console, add an Actuate policy for the Actuate Active Portal resource

Finally, restart all the components and test the resource for SSO.

This section assumes that you have a functional setup of Access Manager, Actuate iServer, and Actuate Active Portal on the same system.

To deploy and install the integration, do the following:

1. Create the executable for publishing reports on Actuate iServer, as follows:



1. As root, install e.Report Designer on a Windows machine.



2. Unzip the content of the Actuate report design package (Reportdesigns.zip) into a project directory.



3. Open the design documents with e.Report Designer and publish them to Actuate iServer.


For details of this step, see the Actuate documentation.

Note that e.Report Designer uses the log files in the default location (/var/opt/SUNWam/logs/). If your server has a different log location, edit the Input-SunLogDataSource file and update the Path variable to reflect the correct value. Be sure to include the trailing / at the end of the path. For example:

This is correct: /var/opt/SUNWam/logs/

This is incorrect: /var/opt/SUNWam/logs


4. Verify that the reports have been published to Actuate iServer by logging in from acadmin, for example, http://v120-29-01.sfbay.sun.com:8900/acadmin/login.jsp.
   
   The report executables are displayed. You can then schedule a report for a trial run.



2. Deploy the Report tab on the Access Manager Console. Do the following:



1. As root, unzip and untar the Console report package (Console_Report.tar) into a separate directory. Type:
   
   # tar xvf Console_Report.tar



2. Copy the JSP file to the deployment directory on Sun Java System Application Server 7. Assuming that /opt is the installation directory, type these two commands (each on one line):
   
   # cd Console_Report

# cp jsp/* /var/opt/SUNWappserver7/domains/domain1/server1/applications/
j2ee-modules/amconsole_1/console/user



3. Add the resource strings from report.properties to the console properties file (amAdminModuleMsgs.properties)at /opt/SUNWam/locale/.



4. Place the Java archive (JAR) file in the console deployment directory, for example, in Sun Java System Application Server 7. Type this command (on one line):
   
   # cd /var/opt/SUNWappserver7/domains/domain1/server1/applications/
j2ee-modules/amconsole_1/WEB-INF/lib

# cp /Console_Report/Console_Report.jar .



5. Restart Access Manager. Type:
   
   # /opt/SUNWam/bin/amserver start



6. Log in to the Console as the top-level administrator, click the Service Configuration tab, and then select Administration Service. Afterwards, add the following to the View Menu Entries attribute:
   
   module105_report|/amconsole/user/UMAdminTabNav



7. Add the following to the Event Listener Class attribute:
   
   com.iplanet.am.console.user.model.UMReportTabListener

To see the new tab, either quit and log in again or refresh the header frame of the Console by clicking one of the other visible tabs. Afterwards, navigate to the Report tab. The Administrative Activity Report is displayed as the default, along with the links for the other two reports. Also, generate the reports with the filters and test to ensure that everything works.

FIGURE 9 portrays the structure of the Actuate reporting design.

FIGURE 9: Structure of Actuate Reporting Design

The Actuate reports also reference libraries of reusable Actuate components (.rol files). TABLE 6 lists the required ones.

TABLE 6 Required Library Files

You can use e.Report Designer to create or edit custom reports.

In some cases, you cannot use the sample reports as generated. This section describes those cases and suggests workarounds.

The SunLogDataSource component in the Actuate report designs currently points to flat files for the data input. Modify the report so that it can capture the data from the database. Irrespective of the data source, the filter logic is largely consistent.

As long as the filters for the report remain the same and Access Manager, Actuate iServer, Actuate Active Portal all reside on the same machine, you can reuse the Web Application Framework-based integration of the Console as is. No changes are necessary.

Ensure that the log files are accessible from Actuate iServer, for example, through Network File System (NFS). The JSP pages for the reports for the Console point to Access Manager in the Web Application Framework form. Edit that form to point to the Fully Qualified Domain Name (FQDN) on which you installed Actuate Active Portal.

To add filters to existing reports generated from the Console or to add reports to be viewed from the Console, do one of the following:

• Edit or create an Actuate report design.
• Edit the Web Application Framework model, view bean, and JSP files.
• Edit the amAdminModuleMsgs.properties file.

The Console JSP files for the reports reference the port number of Actuate Active Portal. Revise those references and point to the nondefault port number you'd like to use. If the Actuate components reside on a separate machine (see Case 2 above), ensure that the form's URL contains the FQDN of that machine.

Currently, the tab listener determines whether to display the Report tab to the user by verifying whether that user belongs to the topleveladmin role in Access Manager. If you use an Active Server Pages (ASP) model, you may need to delegate the ability for generating reports to administrators of suborganizations. Such administrators may not be in the topleveladmin role in the integration, however.

As a workaround, customize the tab listener to check for the suborganization's admin role rather than the topleveladmin role

To generate a report so that it's specific to a user's organization, further customize the report designs and create additional filters to verify the details that pertain to that organization.

Here are two known problems for the integration and the tips for resolving them.

• While running a report from the Console, you sees the following error message:
  

  Status No: 1 :
  Basic Error: 1004
  Module: afc\ptroot.bas
  Line: 498
  
  User error
  

  This error stems from a problem with running transient reports; the reports are transient by default in Actuate iServer. If the directory into which Actuate writes the transient report is cleaned up incorrectly, that error message is displayed.
  
  The ID for this bug is SCR 64943, which has been fixed in Actuate 8. You can obtain a patch for this bug from Actuate eSupport by referencing the bug ID. As a workaround, restart Actuate iServer and rerun the report.
  
  
• The report does not contain any data even though the logs show otherwise.
  
  A possible cause for this problem is that the report executable cannot open the log files. To resolve this problem, do the following:
  
  
  1. Ensure that the SunLogDataSource file contains the correct file names and path to the log files.
     
     
  2. Verify that the Path variable contains the trailing /, for example, /var/opt/SUNWam/logs/.

• Sun Java System Access Manager
  • Main page
  • Developer home
  • Collection of documentation
  
  
• Sun Java Studio's Web Application Framework
  
  
• Actuate Enterprise Reporting

Satish Hemachandran is a software engineer in Market Development Engineering at Sun. He collaborates with ISVs on applications that pertain to Sun Java System Access Manager, Sun Java System Identity Manager, and Sun Java System Portal Server.

Srividhya Narayanan is the engineering lead for identity management at Market Development Engineering at Sun. She focuses on integrating ISV applications with Sun Java System Access Manager and Sun Java System Identity Manager.

Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun for 15 years, mostly in the technical arena.