Book Image

IBM WebSphere Application Server v7.0 Security

By : Omar P Siliceo (USD)
Book Image

IBM WebSphere Application Server v7.0 Security

By: Omar P Siliceo (USD)

Overview of this book

In these days of high-profile hacking, server security is no less important than securing your application or network. In addition many companies must comply with government security regulations. No matter how secure your application is, your business is still at risk if your server is vulnerable. Here is how you solve your WebSphere server security worries in the best possible way. This tutorial is focused towards ways in which you can avoid security loop holes. You will learn to solve issues that can cause bother when getting started with securing your IBM WebSphere Application Server v7.0 installation. Moreover, the author has documented details in an easy-to-read format, by providing engaging hands-on exercises and mini-projects. The book starts with an in-depth analysis of the global and administrative security features of WebSphere Application Server v7.0, followed by comprehensive coverage of user registries for user authentication and authorization information. Moving on you will build on the concepts introduced and get hands-on with a mini project. From the next chapter you work with the different front-end architectures of WAS along with the Secure Socket Layer protocol, which offer transport layer security through data encryption. You learn user authentication and data encryption, which demonstrate how a clear text channel can be made safer by using SSL transport to encrypt its data. The book will show you how to enable an enterprise application hosted in a WebSphere Application Server environment to interact with other applications, resources, and services available in a corporate infrastructure. Platform hardening, tuning parameters for tightening security, and troubleshooting are some of the aspects of WebSphere Application Server v7.0 security that are explored in the book. Every chapter builds strong security foundations, by demonstrating concepts and practicing them through the use of dynamic, web-based mini-projects.
Table of Contents (17 chapters)
IBM WebSphere Application Server v7.0 Security
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface

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?