WAS--like many middleware products--has its own security configuration options that need to be considered when implementing and deploying a WAS application. To someone just getting into the world of WebSphere, these security considerations can be very confusing. Unfortunately, because of the product's complexity, it is difficult to write something less than a book on this topic and still have it be meaningful! This article aims to provide you with an overview of WAS security concepts so that when you investigate this topic further, the information you read will make a bit more sense.

First, the term "WAS security" is a bit of a misnomer, in my opinion. WAS does not really provide security features itself as much as it enables applications to take advantage of the various security features found in the technologies that WAS uses--various Java technologies, protocols, and some of the security features of the operating system upon which the WebSphere server is running.

When writing a WAS application, the idea is to distance oneself from the actual implementation of how a user is prevented from accessing restricted data and concentrate more on defining the appropriate use of the function within the application. In other words, the WAS application should not take it upon itself to perform the actual checks to ensure that the process user has sufficient authority to use a particular method or access a particular database file. Rather, the application should be well-architected to determine all of the roles that apply to the application and what methods should be allowed to be run by which roles. A banking application is popular example of this. The application provides account management functions. The roles defined for the application are Account Holder, Teller, and Supervisor. Depending on the task performed, the method can be defined to be run by one or more of the application roles. How and whether access control is implemented or enforced is up to the WebSphere server--not the application.

Many Layers

The situation that causes WAS security to be so complex and rather difficult to explain is the fact that many contributing technologies and standards (I'll call them "layers") come into play. Figure 1 shows the reality of the situation. Let's take a look at what security features each layer provides.

Figure 1: WAS security has many layers.

The Web Server

If you have used any of the security configuration options of the Apache Web server, these are the first ones that will be evaluated when an Internet or intranet WAS application is running. With the security-related directives Apache provides, you can configure the Web server instance to only serve HTML from specific directories or run programs from specific libraries. You can use directives to require user authentication (that is, demand proof--such as a user name and password--that users are who they say they are) at this layer or later, within the WAS layer. Preferring to implement multiple layers of defense, I think it's a good idea to use the directives within the Web server to restrict what directories can be served as well as what libraries programs can be run from..

For more information on protection directives and other available security configuration options available with the Apache Web server, try the Redbook HTTP Server (Powered by Apache): An Integrated Solution for eServer iSeries Servers.

Java Security

Some of the Java security features available to WAS applications are described below. This is not a complete list, and it may not be current for long. New technologies come along all the time, causing current technologies or interfaces to be "deprecated" That is, something better has come along, and the technology or interface is no longer the one favored by the industry.

Java 2 Enterprise Edition (J2EE)
J2EE provides many middleware application services for server-side application development. WAS 5.1 is J2EE 1.3-compliant. From a security perspective, J2EE 1.3 provides the concept of permissions and, depending on how the policy is defined, the requirement that the user's role must have permission to access the resources in a particular file system.

Enabling permissions allows for the concept of "system integrity." For example, in the case of WebSphere, when you configure the server to enforce J2EE, WAS application code can be prevented from accessing WAS configuration files. While not nearly as robust as the system integrity features of OS/400, this concept of system integrity is similar to the features of OS/400 in that code running in system state can access resources and services not allowed to be accessed by code running in user state.

As alluded to earlier, J2EE also defines the concept of a role. For example, you can restrict access to resources so that only users in the Manager role can access them. J2EE allows two ways for roles to be defined:

• At the time that the application is assembled, thus keeping the definition of the role outside of the application code
• Within the application code itself;

Part of deploying a WAS application is the definition of roles.

Click here for the specifications on J2EE.

Java 2 Security
The basic capabilities provided with Java 2 include these:

• Granular access control by signer or location. Note, this is not user-based access control. Based on trusted entity (signer), the access control is configured in a policy. Based on the policy, unless a permission is explicitly granted to the Java code, it cannot access the resource that is "guarded" by that permission. The definitions within the policy are by code signer or location, not by user or role.
• Security checks for all Java code--not just applets.
• Interfaces and tools for parsing and managing digital certificates, including the X.509 v3 implementation of the certificate interfaces.

CORBA Security Attribute Service (SAS) APIs in the CSIv2 Architecture
SAS provides functionality for CORBA security requirements for client authentication, delegation, and privileges. SAS is used within the Common Secure Interoperability Version 2 (CSIv2) protocol. CSIv2 is the generally accepted standard security protocol for distributed CORBA requests. CSIv2 and SAS are used to enhance communication security--such as an SSL connection--where client authentication is required by the application but cannot for some reason be accomplished or needs to be augmented. SSL will always authenticate the server, but client authentication is not necessarily required. Using SAS, the client can be authenticated. In addition to authenticating the client, the protocol allows the identity of the client to be asserted and possibly be different from the client that was authenticated (this is delegation). Finally, the protocol provides the ability to not only declare the identity of the client but also declare the privileges or rights of the client so that these access rights can be used on subsequent access control decisions on the server.

Java Authentication and Authorization Services (JAAS)
JAAS allows applications to perform user-based authentication and access control. It extends the concepts introduced in Java 2 security that permit access and subsequent execution of code based on who signed the code. JAAS provides the ability to control what Java code is executed based on the "principle"--typically a user--making the request to run the code.

Click here for more information on JAAS.

Java Virtual Machine (JVM)
The JVM that you are running has certain security requirements and can provide security mechanisms itself. Applications running must be in compliance with the version of the JVM that is running. For example, if the system has JVM 1.3 installed, the application must be JVM 1.3-compliant.

Once the application has been written, it is "deployed." Two parts of the deployment process are defining application roles to WAS and associating user identities with a role or roles.

WAS Security Configuration

By default, all of the application server processes share the same security configuration "document" (an XML document stored in the IFS). This document contains global security settings much like OS/400 system values. In other words, the settings in the security configuration document apply across all WAS application server processes. Within this configuration you define the following:

• Whether product security is enforced
• Whether Java 2 security is enforced
• The authentication mechanism that will be used
• The user registry configuration
• Security protocol configurations
• JAAS login configuration
• SSL configurations

Just as some OS/400 system values can be overridden at a lower level, certain WAS security settings can also be overridden at the application level. If an application needs a different security configuration, a document can be defined to address the application's specific security requirements. Settings that can be overridden at the application level include...

• whether application security should be enforced
• whether Java 2 security should be enforced
• security protocol configurations

WAS Administrative Console

As an administrator, you will be using the configuration options in the WAS administrative console.
Users allowed to access the console can be configured to access it in the role of...

• Administrator
• Configurator
• Operator
• Monitor

The Administrator role has the most capabilities. Accessing the administrative console as an Administrator allows you a variety of configuration options (see Figure 2):

• Enable Global Security. Global security protects the integrity of the administrative subsystem and enforces the administrative roles.
• Enforce Java 2 security. This enforces permission checking.
• Activate the protocol to use for CORBA requests. Depending on the other systems the application is communicating with, you will have to specify either CSIv2 and SAS (for communicating with versions prior to WAS 5.1) or CSIv2.
• Specify the Active Authentication Mechanism. If you are passing authentication information between application servers, this determines how the user ID and password are shared between systems--by using either SWAM (which passes clear text user IDs and passwords) or LTPA. (LTPA is the better choice.) Note that all WAS servers that "talk" to each other have to be using the same authentication mechanism or they won't be able to process the user ID and passwords being passed to them.
• Define what user registry the application is going to authenticate against. For all but the most generic applications, some type of user authentication is going to be required. If you are providing an internal application, you will typically require authentication against the Local OS User Registry. In other words, before the results of the application's request is presented back to the requestor, the requestor will have to provide a valid OS/400 user ID and password. However, if you are providing an Internet application and authentication is required, you will probably authenticate against users defined in a non-OS repository such as LDAP.
• Define administrative console users and assign them to an appropriate role (Monitor, Operator, Configurator, or Administrator).
• Enable WAS to use SSL.

Figure 2: The Administrator role allows you to choose configuration options.

OS/400 Security

Last, but certainly not least, OS/400 security comes into play. Since the WAS processes, by default, run under the QEJBSVR user profile, that profile needs authority to the configuration files, the property files, and the code being run and data being served. While QEJBSVR needs authority, the general public does not. Configuration and property files should be set to *OBJAUT(*NONE) and DTAAUT(*EXCLUDE) or at the most, DTAAUT(*X) or *Execute authority. In other words, you will want to monitor access to the files under the '/QIBM/UserData//Base//* ' directory where is WebAS5 if you are running WAS 5.0 or WebAS51 is you are running WAS 5.1 and is the instance of the WAS server.

If you use the "Run as" feature to change the profile under which the application server runs, that profile must be given authority to these resources. I recommend that you use this feature because it is almost always more secure to run an application under a different profile than the one under which the application server itself is running. I also recommend that this be a profile specifically created for this purpose and not an IBM-supplied profile.

For more information, see the Redbook WebSphere Application Server V5 for iSeries as well as the Redbook IBM WebSphere V5.0 Security.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting and services and offering the recently released software, SkyView Risk Assessor for OS/400. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Expert's Guide to OS/400 Security, to be released in May. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..