Testing Struts Applications

In the latest article in the "In pursuit of code quality" series, Andrew Glover discusses a quality-centered approach to the test on Struts, using JUnit's StrutsTestCase, DbUnit. Here is a brief summary :Since the struts Action classes are the entry point to the business logic, there is too much coupling associated with them. Testing struts based application needs the use of a servlet container, HttpServletRequest and HttpServletResponse classes. Simpler tools are available for testing such applications:

• StrutsTestCase is a JUnit extension that specifically targets Struts applications. This framework essentially mocks a servlet container, such that you can run and test a Struts application virtually rather than having to run it in Tomcat. The framework also has a handy MockStrutsTestCase class, which extendsTestCase and handles a lot of the Struts configuration aspects for you (such as loading the struts-config.xml configuration file).
• DbUnit is a JUnit extension that facilitates placing a database into a known state between test runs. Using XML seed files, you can insert specific data into a database, which a test case can then rely on. Moreover, using the DbUnit API, you can easily compare the contents of the database to the contents of an XML file, thus providing a mechanism to verify expected database results outside of application code.

Using these two frameworks together lets you do integration-level testing on Struts apps without the need for browser simulations in JWebUnit etc.

WebSEAL: Secure only login page

login redirects is a new feature in Tivoli Access Manager V5.1 . With this new function, all users are can be to the same configured URL after successful authentication. In order to implement secure login pages followed by secure and unsecure pages, the following steps have to be followed:

1. Install and configure Tivoli Access Manager for e-business with atleast one WebSEAL Server.
2. Define an ACL that requires authenticated access for the chosen secured resources. Remember that an ACL that is not attached to protected resources has no impact.

   • acl create secure-access-for-all

   • acl modify secure-access-for-all set any-other rTl

   • acl modify secure-access-for-all set unauthenticatedl

3. Attach the ACL to the resources requiring authentication. The failure of an unauthenticated request when attempting to access this page will initiate the WebSEAL authentication processing. The precise objects the ACL will be attached to will depends upon the configuration of the environment, namely which host the WebSEAL server is on, and which instance is being used.

   • acl attach /WebSEAL//portal/myportal secure-access-for-all

4. Configure WebSEAL for forms-based authentication over HTTPS protocol by setting the forms-auth parameter to https in the [forms] stanza of the WebSEAL instance's configuration file, that is

   /etc/webseald-.conf

   Note that this indirectly prevents login over HTTP.
5. Configure WebSEAL to share the same user session across HTTP and HTTPS protocols. This change is made in the same configuration file as in the preceding step, by setting the value of the use-same-session parameter of the [session] stanza to true.
6. Configure WebSEAL to automatically redirect to the secure portal page over HTTP. This change is made in the same configuration file as in the preceding step, by setting the value of the login-redirect parameter of the [acnt-mgt] stanza to http://:/portal/myportal. Note that this resource must be accessible to all users, and so it is recommended that the secure-access-for-all ACL described in the first step of this procedure be attached to this resource.
7. Configure WebSEAL to allow for automatic redirects when using the forms authentication method. This change is made in the same configuration file as in the preceding step, by setting the value of the redirect parameter of the [enable-redirects] stanza to forms-auth.
8. Customize the WebSEAL error page for Forbidden (HTTP status code 403) to detect if the user has made the request over HTTP, and automatically redirect to HTTPS to login. Add the code fragment from listing 1 at the top of the file

   /www-/lib/errors//38cf0427.html.

9. Restart the WebSEAL instance. On a machine with multiple instances, ensure that the correct instance is restarted.

Reference:

• Tivoli Security: Using Tivoli Access Manager for e-business with HTTPS for Authentication Only

IBM Security Auditing Service

IBM Security Auditing Service Technology is an integral part of the WebSphere Application Server security mechanisms that assure the integrity of a secure computing environment. Enhancing the primary security functionality that ensures requestors have proper authentication and authorization to controlled resources, the security auditing feature provides a means to record those authentication and authorization events.WebSphere Application Server Version 6 offers a technology preview of the security auditing feature. The WebSphere Application Server is instrumented to generate security auditing records for certain security events. The security audit event generators include authentication, access control, and principal and credential mappings for Java 2 Platform, Enterprise Edition applications. Security auditing event records are useful in answering the following questions:

• Which user at what time attempted to access a given resource?
• Was the access attempt successful or did it fail?

Security auditing is not so much about protecting resources as it is about holding users accountable, providing verifiable evidence for non-repudiation, and enabling vulnerability analysis. The following 5 types of security events are auditable in WebSphere Application Server:

1. AUTHN - Authentication eventent
2. AUTHZ - Access control even
3. MAPPING - J2EE connector architecture credential mapping event
4. ACCESS - J2EE web resource access event
5. LOGOUT - Terminate login session eventnt

Each of the above 5 events may be audited for any of the following outcomes

1. SUCCESS - Request passed authentication and access control check
2. DENIED - Request access was denied
3. REDIRECT - Web request is redirected to the login page
4. FAILURE - Security service provider failed while processing request
5. INFO - Security service provider generated an informational message while processing request
6. WARNING - Security service provider generated a warning message while processing request
7. ERROR - Request generated an error condition

The security audit settings can be modified by going to Secure administration, applications, and infrastructure > Custom properties and modifying the "com.ibm.audit.auditSpecification" property to look like this:

J2EE=EVENT=EVENT-OUTCOME=enabled/disabled

Each event must be seperated by a ":". It will look like this:

J2EE=AUTHN=failure=enabled:J2EE=AUTHZ=failure=enabled

More information can be obtained at WebSphere Application Server Information Center or by downloading the IBM Security Auditing Service Technology Preview.

Authorization in JEE

Most articles on JAAS seem to be centered on Authentication, and having a byline on Authorization, or none at all. Refer to All that JAAS as an example. This is not a criticism of that article, it just shows how Authorization is ignored in most discussions on application security. You will notice this mostly when you try to explain to managers that User Interface Optimization is not a part of authorization or when you try to explain someone what "Instance based Authorization" means. So, it is refreshing to see a new article on Application Authorization alone. The new article on Developerworks titled "Authorization concepts and solutions for J2EE applications" discusses few basic authorization patterns and the state of authorization technology in the Java EE space. Here is a brief summary:

Authorization Patterns

• Role based authorization: Role-based authorization provides access to resources based on the fact that the user is assigned a Role in the application. A "Role" can be defined as a class of users with similar access to the application's functionality. Roles are determined based on a user's group memberships as defined in a user registry. This type of authorization is the standard of the JEE world. It is a coarse-grained form of access control generally defined by URLs or EJB method calls, as defined in the Web and EJB deployment descriptors, or by the use of the getCallerPrincipal() and isCallerInRole() methods available in EJBContext. It is important to note that a Role is different from Groups defined in a User registry. A role is defined by the application functionality, while a group is defined by the organizational hierarchy.
• Instance based Authorization: This pattern provides a more granular level of authorization than is typically provided by J2EE role-based authorization, getting down to the level of an individual object (an particular instance of an EJB, so to speak) within a system. In this case, we are controlling access based on the EJB methods invoked, as well as the arguments passed to them. Instance-based authorization typically protects instances using access control lists (ACLs), which are stored in some type of policy store and can be used to make access decisions. The best way to implement this type solution is through the use of an external security manager, such as IBM's Tivoli Access Manager.
• Ownership relationships: It is a specific case of the instance-based pattern where there is an owner relationship within the data structures of the application between the user and some other protected data. This typically means that the authorization rules have to be embedded into the data access logic of the application itself. One such example would be to present a user with a list of results that are owned by him. In such cases, a the request to the database must contain the user information for filtering the results. Filtering results in the application is inefficient, particulary when results are shown in multiple pages, in which case a single page display may require multiple requests to database. Stored procedures may be optimal places to apply authorization rules for some applications.
• User Interface customization: The dynamic modification of a user interface to only show actions that the user is entitled to perform is often regarded as an aspect of authorization. But is does not constitute authorization as a whole, since web requests can be modified at the client side too.

Developerworks wikis

developerWorks wikis in a new addition to the IBM Developerworks site.

On java.net, there is a new(?) section, java-enterprise. java-enterprise is the top-level project of the java.net community for Enterprise Java. Subprojects include

• blueprints: Java BluePrints Project
• OpenJEE: Open source Java EE.
• appserverunit: Unit Testing for J2EE Components

Weblogic Workshop Studio 3.2

The latest version of BEA Weblogic Workshop Studio has been upgraded to core Eclipse platform, version 3.2 and the Web Tools Project(WTP) version 1.5 (Part of the Callisto release).Following is a list of new features:

• Upgrade to Eclipse 3.2 and WTP 1.5 (the Callisto release of June 30/2006)
• Updated Spring support -- automatic generation of Spring artifacts from O/R mappings
• Improved Kodo support: a Kodo facet, integrated Kodo development license, Kodo tutorial
• Support the final EJB 3.0 spec for persistence.

Improved Debugging features include:

• Hot deployment
• Manual deployment
• Remote debugging

There are some important improvements to infrastructure. Libraries for Hibernate, Kodo, Spring and Struts are downloaded on first use. You can get a discount code on Bill Roth's blog.

WebLogic Diagnostics Framework

WebLogic Diagnostic Framework (WLDF) is a monitoring and diagnostic framework that defines and implements a set of services that run within BEA WebLogic Server processes and participate in the standard server life cycle. WLDF falls somewhere between the old way of monitoring the environment (using the console or developing JMX based monitoring tools) and the fancy third-party JMX and SNMP monitoring tools.Using WLDF, you can create, collect, analyze, archive, and access diagnostic data generated by a running server and the applications deployed within its containers.WLDF includes several components for collecting and analyzing data:

• Diagnostic Image Capture: Creates a diagnostic snapshot from the server that can be used for post-failure analysis.
• Archive: Captures and persists data events, log records, and metrics from server instances and applications.
• Instrumentation: Adds diagnostic code to WebLogic Server instances and the applications running on them to execute diagnostic actions at specified locations in the code, usually at the beginning or end of a method (achieved using AspectJ) . The Instrumentation component provides the means for associating a diagnostic context with requests so they can be tracked as they flow through the system.
• Harvester: Captures metrics from run-time MBeans, including WebLogic Server MBeans and custom MBeans, which can be archived and later accessed for viewing historical data.
• Watches and Notifications: Provides the means for monitoring server and application states and sending notifications based on criteria set in the watches.
• Logging services: Manages logs for monitoring server, subsystem, and application events.

WLDF provides a set of standardized application programming interfaces (APIs) that enable dynamic access and control of diagnostic data, as well as improved monitoring that provides visibility into the server. Independent Software Vendors (ISVs) can use these APIs to develop custom monitoring and diagnostic tools for integration with WLDF.
WLDF was a new feature in WebLogic Server 9.0. WLDF enables dynamic access to server data through standard interfaces, and the volume of data accessed at any given time can be modified without shutting down and restarting the server.
References

• Introduction to Weblogic Diagnostic Framework (WLDF)
• Configuring and using Weblogic Diagnostic Framework

Mastering EJB 3.0 Free eBook

Mastering EJB fourth edition is now available as a free download on the serverside. The new edition has been updated for EJB 3.0. This edition features chapters on session beans and message-driven beans, EJB-Java EE integration and advanced persistence concepts. In-depth coverage of the Java Persistence API and using POJO entities with EJB is also included.

• More than 50% new and revised material
• Four new chapters and one new appendix covering the latest features of the new release
• Basic and advanced concepts (such as inheritance, relationships, and so on) of Java Persistence API defined entities
• Information on integrating EJB applications with the outside world via the Java EE Connector technology
• Tips and techniques for designing and deploying EJB for better performance
• Best practices for EJB 3.0 application design, development and testing
• Complete usage of EJB annotations along with equivalent XML configuration
• Tricks and traps of EJB deployment
• JBoss Workbook that discusses the exercises for each chapter (although the chapters are themselves vendor-agnostic)

WSAD 5.1, WAS 5.0 Support Ends in September

As Bobby Woolf notes, WSAD 5.1 support ends in September. Support for WAS 5.0 is also scheduled to end on the same day. For more information on software support dates, visit the IBM Software support lifecycle page.

Memory Leaks in WebSphere

In their latest article titled "Memory leak detection and analysis in WebSphere Application Server", Indrajit Poddar and Robbie John Minshall discuss the techniques available in WebSphere Application Server 6.1 to address Java heap memory leaks. The following is a brief summary of the article:
There are four common categories of memory usage problems in Java:

• Java heap memory leaks
• Heap fragmentation
• Insufficient memory resources
• Native memory leaks

The common causes for Java heap memory leaks are:

• Insertion without deletion into collections
• Unbounded caches
• Un-invoked listener methods
• Infinite loops
• Too many session objects
• Poorly written custom data structures.

Memory usage problems due to insufficient memory resources can be caused by:

• Configuration issues (allocating too little memory for heap).
• System capacity issues(too little physical memory).

Native memory leaks are memory leaks in non-Java cod, for example:

• Type-II JDBC drivers
• fragmentation in the non-heap segment of the Java process's address space.

WebSphere Application Server and higher provides a two-stage solution for detection and analysis of memory leaks

• In the first stage, a lightweight memory leak detection mechanism running within the production WebSphere Application Server uses inexpensive, universally available Java heap usage statistics to monitor memory usage trends, and provides early notification of memory leaks. An automated heap dump generation facility (available in WebSphere Application Server running on IBM JDKs)generates multiple heap dumps that have been coordinated with sufficient memory leakage to facilitate comparative analysis using MDD4J.
• The second stagethe Memory Dump Diagnostic for Java (MDD4J) is used to analyze heap dumps outside the production application server.

More information in the article ...

Single Sign-On with JA-SIG CAS

The JA-SIG Central Authentication Service was originally developed by Yale University. It has since become a JA-SIG project. JA-SIG CAS provides the following features for web applications and also to non web based services which have a web front end

• Single sign-on across multiple web applications, as well as to core services that aren't necessarily web-based but have a web front end.
• Allow untrusted services offered by organizations other than ITS to authenticate users without having access to their passwords.
• Simplify procedures that applications need to follow in order to perform authentication.
• Localize authentication to a single web application, which makes it easier for users to safeguard their passwords and which lets ITS change authentication logic if necessary without having to change numerous applications.
• Acegi Security framework provides integration with CAS for implementing Single Sign-On for applications implementing acegi security.