From the IBM WebSphere Developer Technical Journal.

The article is based on the security chapter from the book IBM WebSphere: Deployment and Advanced Configuration. It has been significantly updated for WebSphere Application Server V6 and edited to focus solely on hardening. The text has been edited and formatted for publication as a standalone article While this article is based on WebSphere Application Server V6, most of the issues here apply equally well to V5 and V5.1. Where an issue is unique to V6, we will identify it specifically. Nearly everything else applies to all three major releases, although the screen shots and examples are from V6.

Continued from Part 1

This article is the continuation of WebSphere Application Server V6 advanced security hardening, Part 1: Overview and approach to security hardening.

Back to top

Advanced considerations

We will now move on to some more advanced issues that are related to hardening. We are going to discuss:

• Cross cell trust
• Application isolation
• Identity propagation
• Limitations in WebSphere Application Server security

In many case we won't make specific recommendations, but instead provide important information that may help you in your efforts to maintain and manage a secure infrastructure.

Cell trust and isolation

A WebSphere Application Server cell should not span trust boundaries. If you can't trust someone else totally, don't let them manage your cell or manage a machine in your cell. The WebSphere Application Server administrative infrastructure assumes a coarse grained shared trust model throughout the cell. Every application server contains within it the administrative infrastructure, including internal APIs. On the positive, this makes application servers highly independent and robust by eliminating common points of control. Unfortunately, it also negatively impacts isolation. This approach has implications:

• Every application server in a WebSphere Application Server cell has full administrative authority to the entire cell. Should any application server be compromised, they are all compromised.

• Physical machine boundaries (separate computers, LPARs, nodes, and so on) have virtually no impact on cell security. The unit of trust in a cell is all application servers over all nodes.

• Process boundaries have little impact on cell security. Placing applications in separate application server JVMs does little to increase their isolation from a security perspective within a cell.

• Separate operating system identities have little impact on cell security. Because application servers communicate with the rest of the cell using various protocols that aren't managed by the operating systems, normal operating system projections have little effect.

• Every administrator has equal administrative authority (within their assigned authority of administrator, configurator, operator, or monitor) to the entire cell.

This brings us to two key topics: administrative isolation and application isolation.

Administrative isolation

With WebSphere Application Server, all administrators have administrative authority over the entire cell. It is not possible to assign individual's different rights for different applications, different application servers, or different nodes.

If you are concerned about administrative isolation, there are steps you can take today to address these concerns. First, take advantage of the different administrative roles in WebSphere Application Server.

Second, you can create custom administrative tools for the most common administrative operations (application updates, server restarts, and so on). You can restrict these custom tools based on the administrator and the application. There are two viable approaches to this. The first approach is to write custom wsadmin scripts and protect them using operating system permissions to ensure that each administrator can only run the scripts for his servers. The second approach is to write a small Web application that authenticates the administrator using J2EE™ security, and then allows the administrator to perform certain restricted actions based on his access rights. The application itself can use the JMX APIs for administering the cell. Both approaches have been used successfully by IBM customers.

Application isolation

We now turn our attention to what is perhaps the most difficult part of this article. Application isolation in this context is fundamentally about preventing the illicit actions of one application from harming another. These types of attacks are very difficult to prevent. The reality is that infrastructure software products, such as J2EE application servers, have not yet reached the maturity level of multi-user operating systems. They do not provide the kind of robust isolation that an operating system typically provides between multiple users.

Does this affect me?

First and foremost, the weaknesses discussed here are internal only. These weaknesses can only be exploited by applications that are installed into your cell. In IBM's experience, the vast majority of users of WebSphere Application Server, even those with a shared infrastructure, are not impacted by these issues. This is because they recognize that their shared infrastructure is within the company and is running company-approved code. Thus, they usually do not require complete security isolation of applications.

Users of WebSphere Application Server that are affected by the issues raised here typically have extremely rigorous security policies, such as:

• Formal policies that require that applications not have access to other applications' data, even when running in a shared infrastructure.

• With systems that predated WebSphere Application Server, the requirement that every application run under a separate user ID on shared servers had detailed rules about file system permissions, dedicated processes for each application, and had strict audit procedures to enforce these requirements.

• There are strict corporate security guidelines that are rigorously enforced,, including application architecture and code inspections, to ensure compliance. Without code inspections, developers can insert code that violates corporate policy.

• They may also be exceptionally concerned about remote attacks that might compromise one application, and then be used to compromise other applications.

If you do not fall into the above categories, these issues do not apply to you, and you can skip the remainder of this section.

What mitigating actions can I take?

If you are concerned about applications violating the security of other applications, there are steps you can take today to address these concerns:

• Enforce rigorous code inspections of all application code. Couple this with source code management systems that are secure. This way, every code change is tracked to the person that made the change, and code inspections are scheduled and tracked against every code change. In this situation, it is impossible for a single programmer to insert malicious code into your system. Instead, multiple people would have to work together to achieve any compromise.

• If you choose to purchase commercial applications to run on top of WebSphere Application Server, ensure you purchase products only from reliable and trustworthy vendors. Carefully test and monitor applications prior to production deployment and monitor them while in production.

• If absolutely necessary, deploy applications into private WebSphere Application Server cells. You might consider using different cells for different business units or other organizational units based on risk and trust. To limit hardware costs, you can safely run nodes from multiple cells on a single machine or LPAR. Simply run each cell with a different operating system user ID, different encryption keys, and different administrative passwords. This provides complete isolation from a security perspective.

If none of these approaches are acceptable, you can apply application isolation hardening techniques to the infrastructure. Understand that these techniques require a great deal of work. More significantly, they do not provide a guarantee of isolation. Applications in the same cell, even with global security and Java™ 2 security enabled, can potentially compromise other applications in the same cell by accessing resources of those applications or altering the cell configuration. No such compromise has ever been reported. Through configuration of a single cell, there is no way to guarantee that such comprise is impossible.

In spite of our warnings, we will now proceed to document the actions you can take to dramatically improve the security isolation of applications within a cell. As in Part 1, these actions are listed in priority order. To help you tie the hardening techniques provided in this article back to the classes of attack presented in Part 1, for each technique we will include the following graphic:

The four squares will be shaded as appropriate to represent the type of attack this technique helps to prevent:

• N = Network-based
• M = Machine-based
• E = External application-based
• I = Internal application-based.

47. Do not specify component-managed aliases on J2EE resources

Any J2EE application that runs within the cell can potentially access any J2EE resource. This is because resources have JNDI names that can be looked up by any application, and there is no authorization on resource access. Thus, if application A uses an enterprise database, simply by defining the database as a data source, it is possible that application B in the same cell can access this database.

When an application tries to access a resource by calling getConnection() on the resource factory (for example, a data source or a JMS connection factory), WebSphere Application Server will implicitly provide authentication information to the underlying resource if it is available. The decision of what authentication information to provide depends upon the authentication mode and the available J2C authentication aliases. The details are quite complex, but in brief, any application can look up any resource in the JNDI namespace. When this is done, the authentication mode of "application" is used implicitly. This in turn means that WebSphere Application Server will use a component authentication alias if one is available. Thus, any resource defined with a component alias is accessible to any application in the cell. Note that defining resources at different scopes has no impact on security. Resource scopes are simply an administrative convenience.

On the other hand, if only a container alias is defined on a resource (or no alias is specified), then rogue application will not be able to access the resource because when they lookup a resource in the global JNDI namespace, application authentication and thus component aliases are used. If there is no component alias, no implicit authentication will occur.

If you choose to use this approach, you obviously will still want the appropriate applications to have access to these resources. To do this, those applications must specify local resource references in their deployment descriptors to access the resource. Those references can then be bound at deployment time to the correct resources. If the application specifies container managed authentication on the reference, then a container managed alias defined on the resource itself will be used implicitly. A picture may help to make this clear. Figure 16 is a picture of the IBM Rational® Application Developer reference editor where we are specifying container managed authentication on a JMS connection reference.

There are two problems with this approach. First, container-managed aliases are deprecated, but they work just fine. More significantly, you may have noticed that not all resources allow you to specify container managed aliases, such as JMS factories. In that case, you have to provide no default authentication information on the resource. Instead, you must specify, likely during the deployment process, the authentication information for each resource reference in the application (in this case the authentication method does not matter). This is tedious, you can automate it using wsadmin. At least in the case of MDBs, you can specify the authentication information on the activation specification.

48. Do not define a default userid and password on a resource

A corollary of the previous item is that you should not define a default user ID and password on a resource. If you do so, then any application within the cell can look up the resource, and then implicitly use the provided user ID and password.

49. Enable Java 2 security

As we discussed earlier, all application servers contain the WebSphere Application Server administrative infrastructure and thus, the APIs for performing most administrative operations. An application programmer that learns the APIs can write an application that can call any of these APIs, and then perform essentially any administrative operation. In addition, the file system configuration repository contains a great deal of sensitive information (such as passwords). Any application can use ordinary Java I/O to read these files.

WebSphere Application Server includes support for Java 2 security as provided by the standard JDK. IBM has enhanced the Java 2 support to enforce the J2EE specifications as well as to protect the WebSphere Application Server internal APIs from unauthorized access. Simply by enabling Java 2 security, these rules are automatically enforced. Thus, by enabling Java 2 security, substantial additional protections are added to the runtime to prevent illegal application access.

Once Java 2 security is enabled, applications are limited to a very small set of "safe" permissions by default. If an application needs more permissions, it must normally define those requested permissions in the was.policy file contained with the EAR. When the application is run, the was.policy file is read and those permissions are added to the standard set. As should be obvious, this is a potential security hole. Fortunately, the WebSphere Application Server administrative tools warn the administrator when applications request additional permissions. Our advice is carefully review the requested permissions. If any are unexpected (the expected set should be in a carefully reviewed application delivery document), reject the application. There should be a formal process that includes a security review that determines what permissions an application will be allowed.

The process of review and verification on install can be tedious. However, there is an alternative approach. First, for a large set of environments, most applications will need a common set of additional permissions. If this is possible, the infrastructure team can place in the app.policy file the default permissions for all applications on that node. Only applications that need unusual permissions will place them in was.policy and require additional verification. You can take this even further by forbidding the use of was.policy and requiring that all permissions be added to app.policy by the administration team. That complicates deployment in same ways (editing a common file), but reduces the risk of an application obtaining inappropriate permissions.

50. Leverage secure chained delegation

One of the great benefits of an application server is that user identity information is automatically sent between system layers and across applications. This gives you transparent single sign on. Unfortunately, this has one, potentially dangerous side effect: inappropriate impersonation.

The problem here is that when a user authenticates to use application A, it is possible that application A will then make a remote EJB call to application B. Application B then sees the credentials of the original user. Ordinarily that's a good thing. But, what if application A can't be trusted? Then, a user that accesses application A has reason to fear that it might access application B on his behalf using impersonation. Imagine the implications of this if application A is "unimportant", and therefore is developed in an ad-hoc manner; while application B is a highly sensitive application that manages confidential information. The problem here is that application B, simply because it shares a common security realm with application A, now has to trust application A. That's bad.

The good news, is that there is a way around this problem. We can use a new feature in WebSphere Application Server that is roughly described as "secure chained delegation." By using WSSecurityHelper.getCallerList() or getServerList(), application B can determine what applications and servers a request passed through. The APIs return not just the end user identity, but also information from intermediate servers. If application B is a highly sensitive application, it might require that the list be empty -- implying that it is being used directly by the user. Refer to the WebSphere Application Server Information Center for more information on WSSecurityHelper.

51. Protect the TAM WebSEAL TAI password

When SSO is configured between Tivoli® Access Manager WebSEAL and WebSphere Application Server, WebSEAL sends its secret password in the HTTP header on every request to ensure that the TAI can work when invoked. While this is generally not a concern because the connection should be encrypted using SSL, this does expose the WebSEAL password to Web applications running in WebSphere Application Server.

If one of the Web applications running in WebSphere Application Server cannot be trusted, it could potentially take this password, and then open an HTTP connection to an application server and assert any user's identity. This would make it possible for a cleverly written "evil" application to act as anyone.

If you are concerned about this type of attack, which is easily prevented through code inspections, you can prevent untrusted clients from connecting to the Web container. To do this, simply configure a mutually authenticated HTTPS listener on the Web container. Then, an application will be unable to open an HTTPS connection to the Web container as they don't have the right private key (only WebSEAL or the Web server has it).

52. Beware of Custom JMX code's heightened permissions

For MBeans, you need to be aware that their use requires elevated Java 2 security permissions. If an application registers MBeans programmatically with the application server runtime, you must grant the calling code the RuntimePermission Admin Permission that gives that code the ability to perform any administrative operation. Do so with great caution. A good approach is to create a separate module just for registering the MBean and grant only that the needed permissions.

A second way to load MBeans is to specify them administratively as Extension MBeans (this is the recommended approach). This eliminates the problem of having to explicitly grant application code administrative authority, but raises a new issue. The MBeans are now loaded by a fairly low level WebSphere Application Server classloader, which is more trusted. As a result, your MBeans will have substantially more access to WebSphere Application Server APIs then ordinary user code.

If you choose to develop custom MBeans we strongly recommend you carefully review the code and the usage to ensure you are not introducing security weaknesses in the system. Refer to IBM WebSphere: Deployment and Advanced Configuration for more on this.

53. Use dynaCache with caution

DynaCache provides a powerful high performance distributed shared cache for WebSphere Application Server applications. However, there is no access control on DynaCache. Any application running in an application server can access any cache that a given application server has access to. More precisely, any application can lookup any cache in JNDI if the cache is accessible from that server and then see (or modify) all of its contents.

Fortunately, looking up a cache in a remote server will not work, so applications can only see caches that are being replicated to their server. To limit the risk of this, you should do two things. First, where possible, do not place sensitive information in the cache. Secondly, place applications in separate application servers with separate replication domains to ensure that they can't access each other's caches.

54. Use all resources with caution

Many other WebSphere Application Server resources, such as Work Areas, do not provide for application level authorization. As with DynaCache, you need to use these resources with care. We have not examined every single WebSphere Application Server component in this regard. If you are concerned about application isolation, you should carefully evaluate every usage scenario and look for potential weaknesses and act accordingly.

Cross cell trust

Normally, WebSphere Application Server cells do not trust each other, and thus cross cell Single Sign On (SSO) is impossible. However, you can configure cells to support cross cell SSO. There are plenty of good reasons for doing this, but when you do this, you are extending the trust domain of the cells and need to be conscious of the security implications. There are three issues to consider: shared LTPA keys, cross cell Subject propagation, and CSIv2 identity assertion.

Shared LTPA keys

For two cells to transparently participate in an SSO domain, they must share the same realm, share the same LTPA encryption keys, and use compatible SSL keyrings (for server to server traffic). Normally, a realm is exactly the same as a registry, but WebSphere Application Server 6.0.2 allows for a relaxation of this by setting the com.ibm.websphere.security.ldap.logicRealm property. See the WebSphere Application Server Information Center for more information.

Compatible SSL keyrings means that the calling server must have access to the signing certificate that corresponds to the receiving server's certificate as with any SSL communication.

Once you've ensured that two cells share the same LTPA encryption key, you have created a situation where each cell has the ability to create credentials for the other cell. Therefore, if one cell is compromised, both cells are compromised. If you are using multiple cells as a way to achieve application isolation for security reasons, you need to enable Java 2 security to limit access to WebSphere Application Server internal APIs.

CSIv2 identity assertion

If you wish to make cross cell IIOP calls, but want to avoid sharing LTPA encryption keys, it is possible. Instead, you have to use CSIv2 identity assertion (this also works when contacting non-WebSphere Application Server EJB servers). Let's consider a simple scenario. Assume two cells, cell A and cell B, each of which contains servers. Let's assume that servers in cell A need to make RMI/IIOP calls to servers in cell B, but not the reverse. For this to work, we are going to configure CSIv2 identity assertion. Servers in cell A will assert identities to servers in cell B. We will not describe how to configure CSIv2 identity assertion, just the implications of doing so.

For servers in cell B to accept the identity assertion, the upstream server in cell A must authenticate itself first. There are two ways of doing this with CSIv2: basic auth, where the upstream server sends its user ID and password (the server user ID and password); and client certificate authentication, where the upstream server authenticates using its own certificate. WebSphere Application Server supports both approaches.

Once the authentication is complete, the receiving server will verify that the upstream server is trusted to perform identity assertion. This is configured on the CSIv2 configuration panels. After that, the upstream server sends the downstream server the target user's identity information.

Let's consider the trust implications of this approach. Obviously servers in cell B trust cell A as they accept identity assertion from it. If cell A is compromised, so is cell B. But, what are the implications for cell A?

• If cell A sends a user ID and password to establish trust, it is revealing to servers in cell B its server user ID and password, which has full administrative authority. Thus, cell A now completely trusts B. This is not an improvement over just sharing LTPA keys.

• If cell A authenticates using its own certificate, then it reveals nothing to cell B. Cell A has not trusted cell B.

In summary, for cell A to assert identities to cell B, cell B must trust cell A. That much is obvious. If you do not want cell A to trust cell B, use certificate authentication for the server to server authentication step, not basic auth.

Subject propagation callbacks

If you are taking advantage of subject propagation (see Advanced Authentication in WebSphere Application Server) across cells, you must understand that this implies a great deal of trust between the cells. In addition to the requirement for shared LTPA encryption keys, the cell level server identities end up with substantial authority across the cell boundaries.

To make this clearer, let's consider an example. Assume that there are two servers that share an SSO domain. A user accesses server A using a Web browser and obtains an authentication session (represented by an LTPA cookie in the browser). Then, the user accesses server B. Server B will attempt to obtain the user's subject from server A. This is called subject propagation. If the servers are in the same DynaCache replication domain, this happens trivially. If they are not in the same domain, then JMX callbacks are used to obtain the subject. Obviously, servers in different cells are not in the same DynaCache replication domain. Specifically, server B will make a secure JMX call to server A to obtain the user's subject.

As with any administrative call, the JMX call requires authentication and authorization. In this case, server B will sends its server user ID and password to server A. Server A will then validate that password and ensure that the user ID has administrative authority to its cell.

This has significant implications. This means that for cross cell Web layer (called horizontal) subject propagation to work:

• The receiving server (server B) must send its administrative secret password to server A. Server A therefore now knows the server user ID and password for server B's cell, and that id has full administrative authority.

• Server A (really server A's cell) must grant administrative authority to server B's server id. Server B thus has administrative authority over server A's cell.

The net is that both cells now completely trust each other. Each has administrative authority over the other. The same behavior holds with propagation within a cell, but in that case there is no issue because servers within a cell already trust each other and share a common administrative identity.

Note that this does not apply when downstream propagation occurs using IIOP. In that case the upstream server simply sends the subject to the downstream server. No JMX callbacks are required.

Identity propagation

While this topic isn't directly related to security hardening, it is a common problem that we see creep into system designs that don't take into account security early enough. You must always be very careful to track where identities are established and how (if they can be) they are propagated. We've seen far too many designs that simply assume the identity is known when practical technologies make this infeasible. Make sure you carefully analyze identity flow in your applications to prevent disaster late in the development cycle. Here we present two common cases involving external resources, for WebSphere Application Server V6 users and solutions.

Database versus WebSphere Application Server authentication

One of the key challenges of enterprise systems is properly implementing strong system security controls. In a nutshell, critical data needs to be protected with appropriate authorizations. What makes this challenge particularly difficult with multi-tier J2EE systems where J2EE application code contacts a database (using JDBC, SQLJ, or CMP beans) is that, traditionally, the end user's identity information is lost. By "end user" we mean the user on whose behalf the application is running -- that is, if Bob authenticates to the application using standard J2EE security, then Bob is the end user.

In typical J2EE-based systems, the container maintains a pool of authenticated connections. While each end user authenticates to the application server (using one of several J2EE authentication mechanisms), the user's identity information is not available to the database. This is because all database access is performed using one of several common shared connections from the connection pool. Historically, this has resulted in applications having to reinvent existing database level authorization and auditing functions inside the application layer. This is wasteful when done properly and most likely insecure when done poorly.

With WebSphere Application Server V6 there is an elegant solution to this problem. For a detailed explanation of this topic, see Advanced Authentication in WebSphere Application Server.

MDBs do not run under enqueuer's identity

When a message is enqueued to a messaging system, the original caller's identity is not normally relevant. That is, the messaging engine authorizes access to the queue based on the connection identity as we discussed earlier. The queue doesn't usually even record the end user's identity.

When the message is dequeued, typically by an MDB in J2EE, the original caller's identity is not available. And, even if it were available, it will be ignored. MDBs run under either an anonymous J2EE identity or a static run-as identity. They do not execute under the identity of the message enqueuer.

There is no direct support in WebSphere Application Server for addressing this problem. However, as with database identity projection, if you are willing to write some custom code, you can make this work. As of WebSphere Application Server V6.0.2, WebSphere Application Server now supports server side identity assertion. That is, server side code can change its J2EE run-as identity using JAAS without providing a password. Instead, it simply asserts user identity information. Obviously, this has serious security implications so this is disabled by default, but can be provided for by granting the application code the needed Java 2 security permissions and writing an appropriate JAAS login module. This is discussed in the WebSphere Application Server Information Center in the Identity Assertions and Trust Validation section.

WebSphere Application Server limitations

Through careful configuration, you can create a robust highly secure environment using WebSphere Application Server. However, you should be aware of some typically minor and obscure limitations that may impact you.

CRLs not checked

If you wish to use certificates for client authentication, you should be aware that WebSphere Application Server does not provide for Certificate Revocation List (CRL) checking. Therefore, if your client certificates are compromised, they cannot be revoked. As a practical matter, except for special case situations using self-signed certificates and server to server communication, this makes certificate authentication infeasible.

Generally, this is not a serious problem because certificates are most likely to be used for Web browser authentication. In this scenario the certificate is actually validated by the Web server, not by WebSphere Application Server, and the IBM HTTP Server does include CRL checking.

Note that with enough custom code in the Web services layer and/or in a custom UserRegistry (which includes a callout for checking a certificate), you can custom build your own CRL checking.

Target identity not verified

One subtle aspect of secure systems is the concept of validating the target of a request. Normally, when we think of authentication, we think of the server authenticating the client, but what about the reverse? How does the client know that the server is in fact the intended server? Most of us don't realize it, but Web browsers implicitly perform this check every day. When HTTPS is used, the Web browser validates that the hostname of the Web server is the same as the Web server's subject in its certificate. This ensures that the server is actually the server intended by the user (assuming the user knows what hostname they just used -- many aren't that careful).

What may not be obvious is that the check performed by Web browsers isn't some inherent part of SSL, it's a browser specific check performed outside of SSL. The initiator (the calling server) has to specifically perform this check of the certificate. Unfortunately, WebSphere Application Server does not perform this check. Therefore, when an application server (or client) opens an SSL connection to a server, it isn't ensuring that the server is really the intended server. It is possible, although highly unlikely, that a hacker that can compromise your internal DNS or network could then insert a rogue server into a WebSphere Application Server cell and steal information. This would be an incredibly difficult attack (many attacks are far easier). But, you should be aware of this possibility.

You can remove any unneeded signing keys from the application server trust store files to prevent this. You can only use certificates issued by trusted signers to execute this attack. Unverifiable server side certificates will be rejected by clients during the SSL handshake. If the trusted list is small (perhaps containing only one self signed certificate), this attack becomes very difficult.

Back to top

Protect your desktop development environment

When thinking about security hardening, people tend to focus on the production systems, which are clearly the most important. However, you should also spend some time ensuring that other computers, including your desktop systems, are reasonably secure.

For those running Rational Application Developer (or the earlier WebSphere Studio), this is a serious concern. The desktop IDE contains a fully functional embedded WebSphere Application Server run time environment. This application server has open ports and is vulnerable to remote access in precisely the ways described earlier in this article. You need to address this.

Hardening the embedded application server

At a minimum, we recommend enabling global security in the embedded application server test environment. This prevents the most egregious types of attack, where an intruder can use the built in administrative infrastructure to deploy rogue applications onto your desktop. If you are running Rational Application Developer with administrative authority, this is quite serious. You may also wish to take some of the other hardening steps indicated in this article, although ensuring that the administrative infrastructure is secure is by far the most important step.

If you enable global security, you'll need a registry. WebSphere Application Server supports two out of the box: LocalOS and LDAP. You may find it difficult to use either of these registry types from desktop workstations. If that is the case, the best alternative is to configure a custom file registry. IBM provides a sample file registry that is suitable for desktop use. You can find it in source form in the WebSphere Application Server Information Center.

As an alternative to hardening the embedded application server, you might instead choose to install a desktop firewall product that blocks access to your computer. Such an approach can be quite effective if it is configured properly. A firewall that trusts your entire internal corporate network is of little value in this context.

Hardening the agent controller

Rational Application Developer includes a component known as the agent controller, which is used for monitoring application servers. Unfortunately, the default configuration of this tool is completely insecure. It accepts requests from any host without authentication. You can use this to read any file from your computer. When you first install the agent controller, configure it to accept requests only from "this computer," or configure it to authenticate requests. If you use the controller solely to monitor the embedded application server (the typical case), configuring the controller to accept requests only from "this computer" is the best approach.

If you have already installed the agent controller, you can fix the installation after the fact to accept only local requests as follows. Edit the file <RAC_INSTALL>\config\serviceconfig.xml and look for the Hosts configuration stanza. Change it from:

<Hosts configuration="default">
	<Allow host="ALL"/>
</Hosts>

to:

<Hosts configuration="default">
	<Allow host="LOCAL"/>
</Hosts>

Back to top

Conclusion

This two-part article has covered a great deal of ground. We've discussed numerous aspects of security, although we focused on the core theme of hardening a WebSphere Application Server environment. Hopefully, you now have the basic information you need to secure your J2EE systems. While we won't discuss it here, you should look for other sources of information for hardening other parts of your infrastructure. WebSphere Application Server is only one piece of a much larger puzzle.

Finally, you can check a subset of the items described in this article using an automated tool known as the IBM Security Scanner for WebSphere Application Server.

Back to top

Acknowledgements

I would like to thank my colleagues Cameron Martin, Bill Hines, Paul Ilechko, and Tom Alcott for their valuable input and assistance. I'd also like to thank Ching-Yun (C.Y.) Chao and Peter Birk, members of the WebSphere Application Server security development team.

Resources

• Enterprise Application Security, Keys Botzum, 2000
  
  
• CIO Insight: What is social engineering?, Computer Cops, 2003
  
  
• IBM WebSphere Application Server 6.0 Security Redbook, SG- 246316
  
  
• WebSphere Application Server Information Center
  
  
• Understanding and Deploying LDAP Directory Services, Howes, et al, ISBN 0672323168
  
  
• Buffer Overflows -- What Are They and What Can I Do About Them?, Larry Rodgers, CERT, 2001
  
  
• Understanding Malicious Content Mitigation for Web Developers
  
  
• Java Security Coding Guidelines
  
  
• WebSphere Application Server Information Center: Messaging security
  
  
• IBM Security Scanner Tool for WebSphere Application Server, IBM Support
  
  
• IBM WebSphere: Advanced Deployment and Administration, Roland Barcia, Tom Alcott, Bill Hines, and Keys Botzum, ISBN 0-131468-626
  
  
• Advanced Authentication in WebSphere Application Server, IBM WebSphere Developer Technical Journal, August 2005
  
  
• Database identity propogation in WebSphere Application Server V6, IBM WebSphere Developer Technical Journal, June 2005
  
  
• Building Secure Servers with LINUX
  
  
• Firewall Port Assignments in WebSphere Application Server, IBM WebSphere Developer Technical Journal, October 2003
  
  
• www.keysbotzum.com
  
  
• IBM developerWorks WebSphere
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Continued from Part 1
• Advanced considerations
• Protect your desktop development environment
• Conclusion
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Tivoli Access Manager for Enterprise Single Sign-on
• Webcast: Achieve an Agile Organization through Enterprise Architecture
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli Access Manager for Enterprise Single Sign-on

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers