IBM WebSphere Application Server v7.0 Security: For IBM WebSphere users, this is the complete guide to securing your applications with Java EE and JAAS security standards. From a far-ranging overview to the fundamentals of data encryption, all the essentials are here.

The architecture is basic since it only shows the minimum infrastructure components needed by a WebSphere Application Server infrastructure to become functional. In this diagram, the infrastructure elements are presented as they relate to each other functionally. In other words, the diagram is generic enough that it only shows and identifies the components by their main function. For instance, the infrastructure diagram includes, among others, proxy and messaging servers. Nothing in the diagram implies the mapping of a given functional component to a specific physical element such as an OS server or a specialized appliance.

The infrastructure architecture presented in the diagram depicts a WebSphere clustered environment. The only technologies identified by their brand are the IBM HTTP Server (IHS) web server component (represented by the two rectangles (light blue) labeled IHS) and the WebSphere Application Server (WAS) nodes (represented by the rectangles (green) labeled WAS).

These two simple components offer a variety of architectural choices, such as:

The choice for a specific architecture will be made in terms of a variety of requirements for your environment, including security requirements.

The infrastructure diagram also includes a number of components that are only identified by their function but no information is provided as to the specific technology/product implementing the function. For instance, there are four shapes (light yellow) labeled DB, Messaging, Legacy Systems, and Service Providers. In your environment, there may be choices to make in terms of the specific component. Take for instance, the DB component. Identifying what DB server or servers will be part of the architecture is dependent on the type of database employed by the enterprise application being hosted. Some corporations limit the number of database types to less than a handful. Nevertheless, the objective of the WebSphere Administrator responsible for the environment is to identify which type of databases will be interfacing with the WAS environment. Once that fact is determined, the appropriate brand/product could be added to the architecture diagram.

Other technologies/components that need to be identified in a similar way are the user registry (represented by the shape (light purple) labeled User Registry), the security access component (represented in the diagram by the oval (yellow) labeled Security Access). A common type of user registry used in WebSphere environments is an LDAP server. Furthermore, a popular security access product is SiteMinder (formerly by Netegrity, now offered by CA).

The remaining group of elements in the architecture has the function to front-end the IHS/WAS environment in order to provide high availability and added security. Proxy servers may be used or not, depending on whether the IHS function can be brought to the DMZ in its own OS host. Specialized appliances offered by companies such as CISCO or F5 normally implement load balancers. However, some software products can be used to implement this function. An example to the latter is the IBM WebSphere Edge suite. In general, most corporations already own and use firewalls and load balancers; so for the WebSphere administrator, it is just a matter of integrating them to the WebSphere infrastructure.

Some of the benefits of picturing your WebSphere environment using the infrastructure architecture view come from realizing the following important points:

The following diagram depicts a simplified version of the WebSphere Application Server architecture. It presents the application server in the context of a WebSphere node. The application server is the implementation of a JVM. The JVM is made up of various components and at the same time, the JVM interacts with several external components that make up the WebSphere node. So, the diagram presents two major components of a WebSphere environment. On the one hand, the JVM is represented by the parallelogram (purple ) labeled Application Server. On the other hand, a larger parallelogram (teal) labeled node represents the WebSphere node.

Keep in mind that the simplification to the architecture has been done to concentrate on how it relates to application hosting in a secure environment.

The node component of this simplified architecture occupies itself with administrative and thus security aspects between the WebSphere environment and the infrastructure. In the previous diagram, three components can be observed. The first component is the node agent; represented by the small parallelogram labeled Node agent. Notice that the node agent in itself is implemented by a specialized JVM, containing the components required to efficiently perform administrative tasks, which will include security related tasks. The node agent will interact with WebSphere environment administrative components externals to the node (and not included in the diagram). The chief among those external WebSphere components is the Deployment Manager. One of the responsibilities of the node agent as it pertains to the node and thus, to the application server JVM, is to maintain updated and valid copies of the node configuration repository. Such a repository may include information dealing with security domain information, either inherited from the WebSphere cell global security or customized for the node, represented by the parallelogram (black) labeled Local Security Domain.

The second major component of this simplified architecture is the implementation of a JVM. It is represented in the diagram by a large parallelogram (purple) labeled Application Server. A WebSphere JVM is made of, among other components, several containers such as the Web and EJB containers. Containers, on top of hosting instantiations of Java classes such as servlets and beans, that is, offering the runtime environment for those classes to execute, deal with security aspects of the execution. For instance, a Web Container may, given the appropriate settings, oversee that hosted resources only execute if the principal making the request has the required proof that entitles such principal of receiving the result of said request.

In addition to containers, a WebSphere JVM may also instantiate a service integration bus (SIB) if a hosted application makes use of the JVM messaging engine. In the diagram, the arrow (brown) labeled SIB represents the bus. Finally, the other JVM components included in this simplified architecture are the administrative component and the JVM security mechanism. This mechanism will interact with the containers to ensure that security is propagated to the classes executing in the said containers.

From this discussion, it can be extrapolated that each vendor has certain leniency as to the actual implementation of Sun's JVM. IBM is not an exception to this practice. If you wish to find out more about the particulars of the IBM JVM implementation for WebSphere please refer to the Information Center article "Specifications and API" (http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rovr_specs.html). In that article you will find out which Java specifications and application programming interfaces are implemented as well as the version each implements. This information is presented in a neat table that helps you compare each specification and API version to earlier editions of the WebSphere Application Server product (that is, 5.1, 6.0 and 6.1).

The main benefit of analyzing your WebSphere environment using this view is that it will provide you with the vocabulary to better understand the needs of application developers and architects and, equally important, to communicate back to them the special features the WebSphere environment may offer them as well as any possible restrictions imposed by security or other infrastructure characteristics.

An additional benefit provided by this view is that it offers alternatives to troubleshooting application related issues, as you will become more familiar with which JVM components are being used as the runtime environment for a given enterprise application.

At the bottom of the stack there are the primitive technologies. The term primitive in this context does not carry the meaning of backward, but rather that of foundation technologies. In the following diagram, the rectangular (bright green) area located at the bottom of the stack represents the OS platform layer.

In this layer, the presence of the underlying operating system can be observed. In the end, it is the responsibility of the OS to provide the low-level resources needed by the WebSphere environment. Furthermore, it is also its responsibility to enforce any security policies required on such resources. Two of the more prominent OS components as they relate to a WebSphere environment are the file system and the networking infrastructure. Both the file systems and the networking infrastructure are handlers of special resources.

The next layer in this architecture is that of the Java technology. This layer comprehends the core Java technologies and APIs used within the WebSphere environment. In the previous diagram, the layer is represented by the rectangle (teal) in the middle of the stack.

The layer is further broken down into three distinct groups among the Java stack. At the bottom sit the foundational bricks. The Java Virtual Machine and the Java Language Specification. The JVM is the enabler whereas the Language Specification lays down basic and general rules that must obeyed by the entities that will populate the JVM.

The middle brick of this layer is that of Java 2 Security. It includes more sophisticated rules that will enable entities in the JVM to achieve more complex behaviors in harmony with the rest of the inhabitants.

Finally, at the top of this layer there is the J2EE Security brick. It brings additional enablers to the JVM and rules that must be followed by the entities that populate these remote areas of the Java galaxy.

At the top of the technology stack, sits the WebSphere security layer. It builds up on the previous layers and brings on board open and proprietary security bricks to supplement the Java foundation.

In other words, the WebSphere high-level security layer offers conduits using a number of technologies such as LTPA, Kerberos, and so on, that make the WebSphere environment more robust. This layer is represented in the previous diagram by the rectangle (maroon) located at the top.

In general, the number of technologies supported by this layer as well as the implementation version of such technologies is one of the aspects that make up each new WebSphere release.

One of the main benefits of the technology stack view is that it helps WebSphere practitioners involved in various roles to map the various technologies included in this stack to the functional blocks that make up the other two views. Some practitioners will benefit by selecting the most appropriate subset among the classes offered by the WebSphere environment to implement a required functionality. Other practitioners will benefit by integrating into the WebSphere environment the best infrastructure component that will help to enable a piece of functionality required by a hosted application.