Chapter 1. A Threefold View of WebSphere Application Server Security

Imagine yourself at an athletic event. Hey! No, no-you are at the right place. Yes, this is a technical book. Just bear with me for a minute. Well, now that the little misunderstanding is out of the way let's go back to the beginning. The home crowd is really excited about the performance of its team. However, that superb performance has not been yet reflected on the scoreboard. When finally that performance pays off with the long-waited score, 'it' happens! The score gets called off. It is not at all unlikely that a controversial call would be made, or worse yet, not made! Or so we think. There is a group of players and fans of the team that just scored that 'see' the play as a masterpiece of athletic execution. Then there is another group, that of players and coaches of the visiting team who clearly see a violation to the rules just before the score. And there is a third group, the referees. Well, who knows what they see! The fact is that for the same action, there may be several perceptions of the same set of events. Albert Einstein and other scientists provided a great example of multi-perception with the wave-particle duality concept. In a similar fashion, a WebSphere based environment could be analyzed in a number of forms. None of the forms or views is absolutely correct or incorrect. Each view, however, helps to focus on the appropriate set of components and their relationships for a given situation or need.

WebSphere Application Server technology is a long and complex subject. This chapter provides three WAS ND environment views, emphasizing security, which will help the reader connect individual security tasks to the big picture. One view aids the WebSphere administrator to relate isolated security tasks to the overall middleware infrastructure (for example, messaging systems, directory services, and back-end databases to name a few). This is useful in possible interactions with teams responsible for such technologies. On the other hand, a second view helps the administrator to link specific security configuration tasks to a particular Enterprise Application (for example, EJB applications, Service Integration Bus, and many more) set of components. This view will help the administrator to relate to possible development team needs. The chapter also includes a third view, one that focuses on the J2EE technology stack as it relates to security. This view could help blend the former two views. So, in a nutshell, the three major parts that make up this first chapter are:

• The Enterprise Application Server infrastructure architecture view

• The WebSphere Application Server architecture view

• The WebSphere technology stack view

Enterprise Application-server infrastructure architecture view

This chapter starts with the Application Server infrastructure architecture view. The actual order of each of these major chapter sub-sections is really unimportant. However, since it needs to be a beginning, the infrastructure architecture view is thus selected.

A possibly more formal name for what it is desired to convey in this section would be the Enterprise J2EE Application server infrastructure architecture. In this way, the scope of technologies that make up the application-centric architecture is well defined as that pertaining to J2EE applications. Nevertheless, this type of architecture is not exclusive to a WebSphere Application Server Network Deployment environment. Well, it's not in a way. If the architecture does not mention specific implementations of a function, it is a generic view of the architecture. On the other hand, if the architecture view defines or includes specific branded technologies of a function (for example, IHS for a web server function), then it is a specialized architecture. The point is that other J2EE application server products not related to the WebSphere umbrella may use the same generic type of infrastructure architecture.

Therefore, this view has to do with J2EE application servers and the enterprise infrastructure components needed to sustain such application servers in a way that they can host a variety of enterprise applications (also known as J2EE applications). The following diagram provides an example of a basic WebSphere Application Server infrastructure architecture topology:

Note

The use of multiple user registries is new in version 7.0

Simple infrastructure architecture characteristics

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.

Branded infrastructure elements

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:

• Hosting both components in a single OS host under a WAS node

• Host each component in their own OS host in the same sub-network (normally an intranet)

• Host each component in different OS hosts in different sub-network (normally a DMZ for the IHS and intranet for the WAS)

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

Generic infrastructure components

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.

Using the infrastructure architecture view

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

• Identify the technology or technology choices to be used to implement a specific function. For instance, what type of user registry to use.

• An immediate result of the previous point is identifying the corporate group the WebSphere administrator would be working with in order to integrate (that is, configure) said technology and WebSphere.

• Once the initial architecture has been laid out, the WebSphere administrator will be responsible to identify the type of security involved to secure the interactions between the various infrastructure architecture components. For instance, what type of communication will take place between the IHS and the Security Access component, if any. What is the best way to secure the communication channel? How is the IHS component authenticated to the Security Access component?