[DevWorks] WebSphere proxy server routing capabilities in a secured environment

WebSphere proxy server routing capabilities in a secured environment


Introduction
To help deliver sufficient performance at an optimized cost, high volume web sites often depend upon mechanisms that bring content closer to the client. This usually implies some sort of caching and cache management.
While it's essential not to underestimate the load caused by static content, caching static content alone is no longer sufficient for most cases. Today's modern caching mechanisms also have to provide the ability to cache dynamic content as well.
IBM WebSphere Application Server Network Deployment (hereafter referred to as Network Deployment) provides multiple, built-in solutions that can be used as intermediary services and also to provide static and dynamic caching capabilities. In addition to the dynamic caching features available on the application server itself, these also provide caching capabilities:

The IBM WebSphere software product line offers special solutions optimized for application and business data caching as well, such as IBM WebSphere DataPower Appliance XC10.

• HTTP plug-in.
• WebSphere proxy server.
• DMZ secure proxy server.
• Edge components caching proxy.

Each of these solutions has its own advantages and disadvantages. The article Proxy server versus the HTTP plug-in: Choosing the best WebSphere Application Server workload management option provides an excellent overview of intermediary services provided by Network Deployment. Additional valuable information about WebSphere proxy sever placement in the topology and configuration can be found in the two-part article that begins with Super cluster to the rescue, Part 1.
This article takes a closer look at the routing capabilities provided by the WebSphere Proxy server. Also discussed are the required configuration steps for a secured WebSphere Application Server cell that is hosting the content delivered through the proxy server.

---

Back to top

WebSphere proxy server administration overview
The WebSphere proxy server was first introduced in WebSphere Application Server Network Deployment V6.0.2 and required an augmentation of the Deployment Manager profile to become visible. In newer versions of WebSphere Application Server, the WebSphere proxy server is available for configuration out of the box in the Deployment Manager administrative console.
The WebSphere proxy server runs as part of the Network Deployment cell and is therefore not suitable to be placed in the DMZ of the network topology. With Network Deployment V7.0, a hardened and DMZ-ready version of the WebSphere proxy server was released, namely the DMZ secure proxy server. This article, however, will deal only with the WebSphere proxy server that runs inside the cell.
From an administration and configuration perspective, the WebSphere proxy server is a separate server type running inside the WebSphere Application Server cell on managed nodes. You can create and configure WebSphere proxy server definitions in your cell either by opening the WebSphere Application Server administrative console or by using wsadmin for scripting based administration.
To manage the WebSphere proxy servers of your cell using the admin console, navigate to Servers > Server Types > WebSphere proxy servers. You can create a WebSphere proxy server from there following the standard procedure for creating a server. To use the WebSphere proxy server to route requests to applications deployed in the cell, the following minimum configuration must be performed:

1. The PROXY_HTTP_ADDRESS and PROXY_HTTPS_ADDRESS ports of the proxy server definition must be in the host aliases list of the deployed application's virtual host definition.
2. The modules that need to be served through the proxy server must have the Enable Proxy property set (see next section).

Essentially, WebSphere proxy server can route requests to two types of content resources:

• Managed resourcesManaged resources are resources that are managed by WebSphere Application Server, either in the same cell as the WebSphere proxy server or in a remote cell. As these resources are fully under WebSphere Application Server management, the state of each resource and the routing information to that resource is dynamically propagated via the high availability manager's bulletin board service. Routing for managed resources is therefore dynamic; however, depending on the environment it requires proper core group configuration so that the high availability manager can propagate the state for each resource.
  To enable dynamic routing for managed resources, you need to select the Enable Proxy check-box for the deployed application modules; this box is set by default during application deployment.
  To verify that the Enable Proxy option is selected for a module, open the admin console and navigate to Applications > Application Types > WebSphere enterprise application > <application_name> > Manage modules > <module_name> > Web Module Proxy Configuration (Figure 1).
  
  
  Figure 1. Web module proxy configuration
  
  
  The Enable Proxy check-box is active by default, enabling the module for routing by the proxy server. The Web Module Transport Protocol drop down box enables you to choose the protocol being used between the proxy server and the application server (either HTTP or HTTPS).
• Unmanaged resourcesUnmanaged resources are those resources that are not under WebSphere Application Server management and control. Because WebSphere Application Server does not have control over these resources, it has limited knowledge about their current state and availability, and so manual configuration is required. WebSphere proxy server, therefore, can only check the availability on the TCP/IP communication level and whether the server hosting the content is available.
  Furthermore, WebSphere Application Server has no chance to gather routing information for this type of resource, and so routing to unmanaged resources need to be configured manually as well. Typical examples for unmanaged content resources are resources provided by HTTP servers, other J2EE™ application servers, and so on, that are accessible by using HTTP or HTTPS protocol.

---

Back to top

Dynamic routing and core groups
Routing can be accomplished in different ways using the WebSphere proxy server depending on the type of server that is hosting the content and how the environment is built. While managed content resources enable fully dynamic request routing, unmanaged content resources require manual routing configuration.
As mentioned earlier, dynamic routing is only possible for managed resources. Routing information for managed resources is propagated via the high availability manager's bulletin board service. This service propagates routing and availability information based on core groups. This makes the routing configuration for the WebSphere proxy server not a matter of proxy configuration, but rather a matter of core group configuration. Possible configurations are hence limited by the core group configurations that are possible. The WebSphere Application Server Information Center provides detailed information about core group bridging.
As core group configuration is an essential part of the WebSphere proxy server routing configuration task, a good understanding of core groups and core group terminology is required. The following core group terms will be used throughout this article. (See the WebSphere Application Server v7.0 Information Center for more detailed explanations.)

• Core group is a high availability domain within the high availability manager. It defines the set of processes over which direct high availability relationships can be established. Highly available components can only failover to processes in the same core group.
• Access point group defines a set of core groups that are communicating with each other and can exchange high availability information.
• Access point defines a set of application servers in a core group that are used to communicate with other core groups. Application servers configured as bridge interfaces in an access point are called core group bridge servers.
• Core group bridge interface defines the node, application server, and the transport channel chain used to exchange data across core group boundaries.
• Core group bridge service is a high availability manager related service in WebSphere Application Server that enables high availability information sharing between core groups.
• Peer core groups are core groups that are interconnected to exchange core group related information, but they reside in different cells.
• Peer access point is an access point that is used for communication between peer core groups. Each peer access point of a core group requires a corresponding core group access point in the peer cell.

---

Back to top

Sample configuration
While the complexity of configurations is virtually unlimited, Figure 2 shows the sample topology that will be used throughout this article to demonstrate the dynamic routing capabilities and the required configuration for the WebSphere proxy server.

Figure 2. Sample topology being used

This topology consists of two cells. The first cell, d0002, hosts the proxy server and is split into two core groups, DefaultCoreGroup and WebCoreGroup. The proxy server is a member of the DefaultCoreGroup. The second cell, d0003, contains one core group, DefaultCoreGroup. By configuring core group bridging, the proxy server of cell d0002 has the ability to dynamically route traffic not only to the application servers in the same core group (d0002-DefaultCoreGroup), but also to applications deployed to servers in different core groups (d0002-WebCoreGroup), as well as to applications deployed to a different cell (d0003-DefaultCoreGroup).
As a best practice for a production environment, the environment will be secured with WebSphere Application Server security. Therefore, all administrative communication within the cell will be authenticated, authorized, and encrypted. However, it is the administrator's responsibility to ensure that the communication to other systems (such as LDAP server, database server, and so on) is secure as well.

---

Back to top

WebSphere Application Servers in the same cell and in the same core group
In this scenario, the WebSphere proxy server is located in the same cell and same core group as the WebSphere Application Server hosting the application to which requests should be routed. Figure 3 shows a simple topology using a cluster of proxy servers (for high availability and load balancing reasons).

Figure 3. Routing to application servers in the same core group

This configuration is the very basic setup for routing requests via the WebSphere proxy server to managed content servers. This setup requires only minimal configuration for routing traffic. The steps to implement a WebSphere proxy server and route traffic to application servers in the same cell and core group only require that proxy is enabled for the application modules. It does not even require mapping modules to the proxy server. Simply setting the Enable Proxy option for the application modules is sufficient.

---

Back to top

WebSphere Application Servers in the same cell but in a different core group
In this setup, the proxy server routes traffic to application servers in the same core group as the proxy server itself, as well as to managed content servers in different core groups of the same cell.
Figure 4 shows a topology of a single cell configuration using a cluster of proxy servers to route requests to application servers that are part of the same core group as the proxy servers (DefaultCoreGroup) as well as to a different core group (WebCoreGroup). Note that a core group bridge needs to be configured between these two core groups to enable the core groups to exchange state and availability information.

Figure 4. Routing to application servers in a different core group of the same cell

As mentioned earlier, routing and availability information for managed resources is propagated using the high availability managers bulletin board service. Although core groups define boundaries for the exchange of availability information within the WebSphere Application Server cell, the core group bridge service enables exchange of high availability information among core groups within the same cell, as well as among core groups in different cells.

To ensure that the proxy server can route requests properly, at least one core group bridge interface server must be active in each core group. For availability reasons, you should configure two core group bridge interface servers on different nodes in each core group. Configuration of more than two core group bridge interface servers increases the memory and CPU overhead and should only be done in specific, well considered situations. One example might be if the nodes of each core group are spread across more than two servers, and resiliency needs to be maximized so that failures or maintenance of two servers does not interrupt core group bridge communication. Furthermore, keep in mind that the core group bridge service consumes memory and CPU resources. Therefore, a best practice is to configure dedicated servers to act as core group bridge interface servers and configure their monitoring policy for automatic restart.

The basic steps to set up the core group bridge service between two core groups in the same cell can be summarized as:

1. Define an access point group (or use the existing DefaultAccessPointGroup).
2. Configure the core group access points for each core group in the access point group.
3. Configure the core group bridge interfaces for each core group access point.

The next steps will describe the configuration of a core group bridge between the DefaultCoreGroup and the WebCoreGroup in detail. The topology being used is outlined in Figure 2. The creation of the WebCoreGroup and the assignment of the required application servers to the WebCoreGroup is a prerequisite for setting up the core group bridge.
Figure 5 shows the core group bridge settings in the admin console with two core groups configured before bridging is setup.

Figure 5. Core group bridge settings for two core groups before bridge configuration

In general, using a consistent naming convention makes administration easier and more accurate.

Table 1 provides an overview about the configuration objects being used to configure the core group bridge service for the sample topology.

Table 1. Core group bridge configuration parameters

Cell	Core group	Node	Core group access point name	Core group bridge interface server	Hostname / IP address	DCS port of bridge interface server
d0002	DefaultCoreGroup	hhuelinux_m00021	d0002_dft_ap01	d0002DftCgBr_01	hhuelinux	41266
		hhuelinux_m00022		d0002DftCgBr_02		42266
d0002	WebCoreGroup	hhuelinux_m00021	d0002_web_ap01	d0002WebCgBr_01	hhuelinux	41291
		hhuelinux_m00022		d0002WebCgBr_02		42291

To setup the core group bridge between the two core groups, perform these steps:

1. In the WebSphere Application Server administrative console for cell d0002, navigate to Servers > Core Groups > Core group bridge settings.
2. Core groups communicate between each other through core group access point groups. To create a bridge between two core groups in the same cell for this scenario, the predefined DefaultAccessPointGroup can be used. Add the core group access points by configuring the core group bridge interface server for WebCoreGroup using the DefaultAccessPointGroup. Click on DefaultAccessPointGroup, as shown in Figure 6.
   
   Figure 6. Selecting the core group access point
   
   
3. Click on Core group access points to configure the core group access point for the WebCoreGroup (Figure 7).
   
   Figure 7. Configuration of the core group access point
   
   

An access point group must have only one core group access point per core group when the access point group also contains peer access points.

5. In the core group access point panel, you can update existing core group access points by selecting them and pressing Show Detail or create new ones by clicking New. Figure 8 shows how to select a core group access point to update the settings.
   
   Figure 8. Selecting a core group access point for editing its values
   
   

While not required, it is however a good practice to give the core group access point a meaningful name.

6. The configuration of the core group access point basically requires the configuration of:
   1. Core group access point name.
   2. The core group for which the access point is configured.
   3. Definition of bridge interfaces.
   4. Custom properties.
   Enter the name of the core group access point and select the core group for which the access point is defined from the drop down box (Figure 9). Press the Apply button and click Bridge interfaces to configure the bridge interface servers.
   
   Figure 9. Renaming the core group access point and selecting the bridge interfaces
   
   
7. Repeat these steps for every core group bridge interface server you want to add to this core group access point:
   1. Click New to add a new bridge interface server (Figure 10).
   2. Select the server that should act as core group bridge interface server from the drop down box according to #Table 1 Coregroup bridge configuration parameters. Figure 10 shows the defined bridge interface servers for the DefaultCoreGroup.
   
   
   Figure 10. Configured bridge interface servers for DefaultCoreGroup
   
   
8. Repeat steps 5 though 9 for the WebCoreGroup to define the bridge interface servers for that core group.
9. When all core group bridge servers for the core group access point group are defined, go back to the core group bridge settings panel by clicking Core group bridge settings in the breadcrumb path. Expand the entries to check your core group bridge settings.

Core group communication runs via the DCS ports of the servers. Therefore, make sure that these ports are open on the firewalls in the case core groups are in different network zones separated by firewalls.

12. Figure 11 shows the DefaultAccessPointGroup with all access points, core group bridge servers, and their attributes expanded, giving an overview of the bridge configuration and the associated network configuration. In this overview of the core group bridge configuration in cell d0002, you can see that the DefaultCoreGroup is bridged to the WebCoreGroup via the DCS ports of servers d0002DftCgBr_01, d0002DftCgBr_02, d0002WebCgBr_01 and d0002WebCgBr_02.
    
    Figure 11. Core group bridge settings with all bridge interfaces
    
    
13. Shutdown and restart all configured core group bridge interface servers in that access point group and verify via the JVM logs that the bridges are working. Check for the following messages in the logs:
    • CWRCB0106I
    • CWRCB0107I
    Listing 1

    [11/27/11 16:38:37:081 IST] 00000008 CGBridge I CWRCB0106I: This core group bridge service (d0002\hhuelinux_m0002 1\d0002DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41266 [11/27/11 16:38:54:009 IST] 00000008 CGBridge I CWRCB0107I: This core group bridge is stable and has the following Access Point Group member(s) available: DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

Once you have confirmed that the core group bridge service is working, you are ready to access your applications in both core groups via the WebSphere proxy server. To access the applications deployed to the WebSphere Application Server(s) in each of the core groups using HTTP protocol, you need to specify the PROXY_HTTP_ADDRESS port of the proxy server in the browser's URL (for example, 80). To access your applications via HTTPS protocol, use the PROXY_HTTPS_ADDRESS port of the proxy server in the browser's URL (for example, 443). The hostname used to access the applications is the Internet host name of the WebSphere proxy sever. Therefore, the URL used to access the web module of Information.ear, for example is: https://proxyhost/info/Information.jsp and the URL to access the web module of CoeTest.ear is https://proxyhost/jdbctest/index.jsp.

If requests routed by the WebSphere proxy server result in a 503 HTTP return code (among others), common causes could be:

• The core group bridge is not working properly. Check and verify that at least one core group bridge server in each core group access point is running.
• The enterprise application itself is not started.

This is now a good time to test and ensure that applications can be accessed via the proxy server. Based on the sample topology in Figure 2, these applications should now work:

• Information.ear
• CoETest.ear

Keep in mind that at least one core group bridge interface server in each core group must be up and running.
See the WebSphere Application Server Information Center for detailed information about setting up the core group bridge service.

---

Back to top

WebSphere Application Servers in a different cell than the proxy server
In this setup, the proxy server routes traffic to application servers in the same core group as the proxy server itself, to application servers in a different core group but in the same cell, and to managed content servers in a remote cell.
Figure 12 shows the topology of a configuration using a cluster of proxy servers to route requests to application servers that are part of the same core group as the proxy servers (DefaultCoreGroup), as well as to a different core group (WebCoreGroup) in the proxy server’s cell (d0002). In this scenario, the proxy servers also route requests to application servers in a cell (d0003) that is different than the proxy server's cell . A core group bridge needs to be configured between the two core groups in the same cell, as shown in the previous scenario. In addition, a peer core group bridge has to be established between the core group of the proxy server and the remote cell to which requests should be routed.

Figure 12. Routing to application servers in a different cell

As mentioned earlier, routing and availability information for managed resources is propagated using the high availability manager's bulletin board service. However, core groups define boundaries for the exchange of availability information within the WebSphere Application Server cell. Therefore, you need to configure the core group bridges to enable the exchange of high availability information between the core groups and the cells. The required core group configuration for routing requests to the applications deployed to servers in a separate core group of the same cell is documented above. Here, we'll focus on the core group configuration required to route requests to servers in a remote cell, also called peer core group bridges.
To bridge core groups across cells, ensure the following conditions are met:

To ensure that the proxy server can route requests properly, at least one core group bridge interface server must be active in each core group. For availability reasons, you should configure two core group bridge interface servers on different nodes in each core group. Configuration of more than two core group bridge interface servers increases the memory and CPU overhead and should only be done in specific, well considered situations. For example, if the nodes of each core group are spread across more than two servers and resiliency needs to me maximized so that failures or maintenance of two servers does not cause an interruption of the core group bridge communication.
Furthermore, keep in mind that the core group bridge service consumes memory and CPU resources. Therefore, it's a best practice to configure dedicated servers to act as core group bridge interface servers and to configure their monitoring policy set for automatic restart.

• The cells between which you are configuring core group bridge communication must have unique names.
• The core group access point groups used to connect the two peer core groups must have the same name in each cell.
• Each access point group must contain:
  • One core group access point for the core group of the local cell.
  • One core group access point for each of the core groups in the remote cells.
  • The same core group bridge servers must be used for bridging between core groups in the same cell and for bridging to core groups in remote cells.
• When working in a secured environment (which production environments usually are), there are some additional conditions what need to be considered when setting up a core group bridge across cells, namely:
  • The security realm names in both cells must match.
  • The cells must trust each other, hence the signer certificates between two cells must be exchanged.
  • The LTPA keys between the cells must be exchanged. Therefore, the automatic regeneration of the LTPA keys will break the core group bridge unless proper manual actions are taken. For that reason, you should consider disabling the automatic regeneration of LTPA keys.

To setup the core group bridge service between two cells:

1. Define an access point group. Keep in mind that the access point group names must match in both cells.
2. Configure the core group access points for each core group in the access point group.
3. Configure the core group bridge interfaces for each core group access point.

The steps below describe the configuration of a core group bridge service between cells d0002 and d0003. In both cells, the core group bridge interface server will be a member of the DefaultCoreGroup.
Table 2 provides an overview about the configuration objects being used to configure the core group bridge service:

Table 2. Coregroup bridge configuration parameters for peer core group bridge

Cell	Core group	Node	Core group access point name	Core group bridge interface server	Hostname / IP address	DCS port of bridge interface server
d0002	DefaultCoreGroup	hhuelinux_m00021	d0002_dft_ap01	d0002DftCgBr_01	hhuelinux	41266
		hhuelinux_m00022		d0002DftCgBr_02		42266
d0003	DefaultCoreGroup	hhuelinux_m00031	d0003_dft_ap01	d0003DftCgBr_01	hhuelinux	41366
		hhuelinux_m00032		d0003DftCgBr_02		42366

The required steps to setup this environment must be performed for each cell using the appropriate configuration values. First, the configuration steps for cell d0002:

1. Open the WebSphere Application Server administrative console for cell d0002 and navigate to Servers > Core Groups > Core group bridge settings .
2. Select Peer access points as shown in Figure 13.
   
   Figure 13. Configuration of peer access points
   
   
3. Click New to create a new peer access point.
4. Enter configuration as per the configuration values in Table 2 (Figure 14).
   
   Figure 14. Creating a new core group peer access point
   
   
5. Click Next to proceed to the next panel.
6. Enter the DCS connection information for the first bridge interface server in the remote cell. In your setup, this is the first core group bridge server of the DefaultCoreGroup in cell d0003. As per Table 2, this is the hostname and the port name of server d0003DftCgBr_01. Figure 15 illustrates the configuration of the first peer port definition.
   
   Figure 15. Configuration of the core group access point peer port
   
   
7. Click Next to proceed to the summary panel.
8. Click Finish to finalize the creation of the first peer access point.
9. To add additional peer access points, click on the peer access point name as shown in Figure 16.
   
   Figure 16. Select the core group peer access point to add a port
   
   
10. Click on Peer ports to add an additional access point port for high availability of the peer core group bridge (Figure 17).
    
    Figure 17. Adding additional peer port definitions
    
    
11. Click New to add an additional peer port.
12. Enter the DCS connection information for the second bridge interface server in the remote cell. As per Table 2, this is the hostname and the port name of server d0003DftCgBr_02.
13. Click again on Peer ports to verify the peer port definition for the peer access point (Figure 18).
    
    Figure 18. Verification of the peer port definitions
    
    

Configuring core group access point group for bridging to d0003
The next major step is to configure the core group access point group for the core group bridge service. During creation of the core group access point group, you can assign the access points and the peer access points in the same step. Alternatively, you can assign the access point information to the group later. For this example, you will create an empty access point group first, and then assign the access point and the peer access points later.

Remember that the access point group names must match in both cells.

1. In the WebSphere Application Server administrative console for cell d0002, navigate to Servers > Core Groups > Core group bridge settings > Access point groups, then click New.
2. Enter the name of the core group access point group you are going to create in the Access point group name field. In this scenario, the name will be dft_d0002_to_dft_d0003.
3. Click Next through the next three panels and then click Finish.
4. Click on the name of the access point group you just created, as shown in Figure 19.
   
   Figure 19. Selection of the core group access point group to add access points
   
   
5. To assign peer access points, click on Peer access points in the Access points container.
6. Select the previously created peer access point from the available peer access points container and click the right arrow to assign the peer access point to the access point group, as shown in Figure 20.
   
   Figure 20. Adding a peer access point to an access point group
   
   
7. Click OK.
8. Next, assign the access point for the local core group to the access point group. This step can be skipped if the cell contains only one core group. Click on Core groups access points in the Access points container, as shown in Figure 21.
   
   Figure 21. Adding the local access point to the core group access point group
   
   

To achieve maximum resiliency of the core group bridge, each bridge interface server should run on a separate node and a separate system.
Core group communication runs via the DCS ports of the servers. Therefore, make sure that these ports are open on the firewalls in case core groups are in different network zones separated by firewalls.

9. Select the core group access point you want to add from the available peer access points container and click the right arrow to assign the access point to the access point group, as shown in Figure 22. In this example, you are configuring a core group bridge between the DefaultCoreGroup in cell d0002 and the DefaultCoreGroup in cell d0003. Therefore, the d0002_dft_ap01\DefaultCoreGroup access point has to be selected and added to the core group access point group.
   
   Figure 22. Selection of the access point to be added to the core group access point group
   
   
10. Click OK.
11. Click on Core group bridge settings in the breadcrumb trial. Expand the entries to verify your core group bridge settings.
    
    Figure 23. Overview of the core group bridge configuration for cell d0002
    
    

Figure 23 shows both core group access point groups of cell d0002 with all access points, core group bridge servers, and their attributes expanded, giving an overview of the bridge configuration and the associated network configuration. In this overview of the core group bridge configuration in cell d0002, you can see that the DefaultCoreGroup of cell d0002 is bridged to the DefaultCoreGroup of cell d0003 via the servers d0002DftCgBr_01 and d0002DftCgBr_02. The core group bridge traffic flows between these two servers and the servers having the DCS port listening on server hhuelinux.huebler.at:41366 and hhuelinux.huebler.at:42366.
This completes the core group bridge configuration for cell d0002.
Core group bridge configuration of cell d0003
Next, you will repeat the same configuration steps for cell d0003. These steps must be performed for cell d0003 using equivalent naming. The configuration values can again be determined from Table 2. As the steps are basically the same, they are simply summarized here:

1. In the WebSphere Application Server administrative console for d0003, navigate to Servers > Core Groups > Core group bridge settings.
2. Because the core group access point group names between cell d0002 and d0003 must match, the first step is to create the core group access point group named dft_d0002_to_dft_d0003.
3. Click on the core group access point group name and select Core group access points.
4. Under the available core group access points, click CGAP_1\DefaultCoreGroup and select Show detail.
5. Rename the core group access point and add the bridge interface servers, as per Table 2. The required steps are shown in detail in Figure 9.
6. Add the d0003_dft_ap01 core group access point to the core group access point group dft_d0002_to_dft_d0003.
7. Configure the peer access points for cell d0002, as descibed in Figure 13, and add the peer access point d0002_dft_peer_ap01 to the core group access point group dft_d0002_to_dft_d0003.
8. The core group bridge configuration for cell d0003 should appear similar to that shown in Figure 24.
   
   Figure 24. Core group bridge configuration for cell d0003
   
   
9. Shutdown and restart all configured core group bridge interface servers in both cells.
10. Start the core group bridge servers for cell d0002 and verify via the JVM logs of the core group bridge servers that the bridges are working. Check for these messages in the logs:
    • CWRCB0106I
    • CWRCB0107I
    After starting the core group bridge servers of cell d0002 only and verifying the SystemOut.log of the core group bridge servers for the DefaultCoreGroup of cell d0002, the messages shown in Listing 2 indicate that the bridge to the WebCoreGroup is working fine. However, the message NO BRIDGES for the access point group dft_d0002_to_dft_d0003 indicates that the bridge to cell d0003 is not available at this time.
    
    Listing 2
    

    [12/6/11 12:08:58:846 IST] 0000000b CGBridge I CWRCB0106I: This core group bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41266 [12/6/11 12:08:58:850 IST] 0000000b CGBridge I CWRCB0107I: This core group bridge is stable and has the following Access Point Group member(s) available: DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup NO BRIDGES dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

11. Start the core group bridge servers for cell d0003 and verify via the JVM logs of the core group bridge servers that the bridges are working. Check for the following messages in the logs:
    • CWRCB0106I
    • CWRCB0107I
    After starting the core group bridge servers of cell d0003 and verifying the SystemOut.log of the core group bridge servers for the DefaultCoreGroup of cell d0003, the message NO BRIDGES for the access point group dft_d0002_to_dft_d0003 still indicates that the bridge to cell d0002 is not available, although the core group bridge interface servers are up and running (Listing 3).
    
    Listing 3
    

    [12/6/11 13:19:19:685 IST] 00000009 CGBridge I CWRCB0106I: This core group bridge service (d0003\hhuelinux_m00031 \d0003DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41366 [12/6/11 13:19:19:694 IST] 00000009 CGBridge I CWRCB0107I: This core group bridge is stable and has the following Access Point Group member(s) available: dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES [12/6/11 13:19:19:702 IST] 00000009 CGBridge I CWRCB0108I: The core group bridge service is currently unstable for Access Point Group(s) DefaultAccessPoint Group. [12/6/11 13:19:21:487 IST] 0000000a CGBridge I CWRCB0106I: This core group bridge service (d0003\hhuelinux_m00031\d0003DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41366 [12/6/11 13:19:21:495 IST] 0000000a CGBridge I CWRCB0107I: This core group bridge is stable and has the following Access Point Group member(s) available: DefaultAccessPointGroup d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES

12. Further checking of the SystemOut.log shows that the HMGR0149E error message (Listing 4) was raised as well, leading you to the core of the problem.
    
    Listing 4
    

    [12/6/11 13:19:41:763 IST] 00000023 DefaultTokenP E HMGR0149E: An attempt to open a connection to core group dft_d0002_to_dft_d0003 has been rejected. The sending process has a name of 127.0.0.1:41266 and an IP address of /127.0.0.1. Global security in the local process is Enabled. Global security in the sending process is Enabled. The received token starts with lf>c%$oO. The exception is com.ibm. websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due to invalid keys or token type. at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken (LTPAServerObject.java:1161) at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken (LTPAServerObject.java:1078) at com.ibm.ws.security.token.WSCredentialTokenMapper.validateLTPAToken (WSCredentialTokenMapper.java:1376) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider.authenticateMember (DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.dcs.MemberAuthenticatorImpl. authenticateMember(MemberAuthenticatorImpl.java:87) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery.DiscoveryRcv. acceptStream(DiscoveryRcv.java:185) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.fetchStream(Packet Processor.java:470) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.run(PacketProcessor.java:860)

    
    You are getting the HMGR0149E error message because you are trying to establish a core group bridge between two cells with security enabled (which should be the case in any production environment) but did not yet set up SSO between the cell.

The core group bridge service uses the LTPA authentication mechanism for cross-cell authentication.

13. You need to follow the Lightweight Third Party Authentication and Single sign-on for authentication using LTPA cookies setup in WebSphere Application Server to enable authentication via LTPA for the peer core group bridges. The key points to be considered can be summarized as:
    • Sharing of the LTPA keys between the cells. To avoid future problems the automatic regeneration should be disabled and new keys should be regenerated and distributed manually.
    • The sever date and time must be synchronized.
    • The user registry must be a centrally managed registry, like LDAP or Windows® Active directory.
    • If you are using a secured environment implementing LDAPS protocol to connect to the LDAP server, import the signer certificate of the LDAP server's server certificate into the truststore being used by the WebSphere proxy server. By default, that is the CellDefaultTrustStore in WebSphere Application Server V7.0.

When using SSL to access your site, you need to add the signer certificate of the content server’s server certificate to the trust store being used by the proxy. Make sure that you really add the signer certificate to the trust store being used by the proxy and not the server certificate! Because WebSphere Application Server uses a sort of mini-CA, one signer certificate is used to sign all certificates of a cell. Therefore, exchanging this signer certificate (root) between the two cells is usually sufficient.

14. If you are planning to use HTTPS protocol to access your web page, the WebSphere proxy server will use SSL to access the servers that host the application via the WC_defaulthost_secure port. While this is usually not a problem as long as the server is in the same cell (the default in WebSphere Application Server V7.0 and later; all servers in the cell trust each other) this requires the exchange of the signer certificates if the proxy server and the content server are in different cells. Failing to exchange the signer certificates results in a CWPKI0022E: SSL HANDSHAKE FAILURE: error message, followed by a CWPKI0428I: The signer might need to be added to the local trust store error message in the proxy server’s SystemOut.log. In that case, the end user will get a 503 Service Unavailable response code.
15. Once the previously mentioned points are taken care of and the servers are restarted, the core group bridge servers of the proxy cell’s (d0002 in our scenario) default core group should contain the proper messages indicating that the core group bridge service is established between the two cells. Check for these messages in the logs:
    • CWRCB0106I
    • CWRCB0107I
    
    
    Listing 5
    

    [12/7/11 14:43:05:039 IST] 0000000b CGBridge I CWRCB0106I: This core group bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41266 [12/7/11 14:43:05:045 IST] 0000000b CGBridge I CWRCB0107I: This core group bridge is stable and has the following Access Point Group member(s) available: DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

Once you have confirmed that the core group bridge service is working, you are ready to access your applications in both core groups via the WebSphere proxy server. To access the applications deployed to the WebSphere Application Servers in each of the core groups using HTTP protocol, you need to specify the PROXY_HTTP_ADDRESS port of the proxy server in the browser's URL (80 in this example). For accessing your applications via HTTPS protocol, use the PROXY_HTTPS_ADDRESS port of the proxy server in the browser's URL (443 in this example). The hostname used to access the applications is the Internet host name of the WebSphere proxy sever.
Therefore, the URL used to access the web module of Information.ear, for example, is: https://proxyhost/info/Information.jsp and the URL to access the web module of CoeTest.ear is https://proxyhost/jdbctest/index.jsp. Following the same rule, the web module DefaultApplication.ear, which is deployed to cell d0003 using a context root of /dft, is accessible via the WebSphere proxy server using the URL https://proxyhost/dft/snoop.

If requests routed by the WebSphere proxy server result in a 503 HTTP return code, or similar, here are the most common causes:

• The core group bridge is not working properly. Check and verify that at least one core group bridge server in each core group access point is running.
• The enterprise application itself is not started.
• Problem with the SSL setup across the different cells.

It is now time to test and ensure that the following applications can be accessed via the proxy server. According to the sample topology outlined in Figure 2, these applications should work now:

• Information.ear
• CoETest.ear
• DefaultApplication.ear

Keep in mind that at least one core group bridge interface server in each core group must be up and running.

---

Back to top

Routing to unmanaged resources
In contrast to managed resources and dynamic routing, manual routing configuration must be performed for unmanaged resources because unmanaged resources are not under WebSphere Application Server management and control. Therefore, no state information can be exchanged via the core group mechanism.
Figure 25 shows how the WebSphere proxy server can be used to route requests to unmanaged servers. It demonstrates that the unmanaged servers that are serving requests are required to be configured as members of a generic server cluster in WebSphere Application Server.

Figure 25. Routing of requests to unmanaged servers.

Configuration of generic server clusters
The first step in using the WebSphere proxy server to route requests to unmanaged resources is to configure a generic server cluster in WebSphere Application Server. To configure a generic server cluster in your WebSphere Application Server cell:

1. In the admin console of the cell hosting your WebSphere proxy server, navigate to Servers > Clusters > Generic server clusters > New.
2. Enter the name of the generic server cluster you want to create and the protocol (HTTP or HTTPS) to be used (Figure 26).
   
   Figure 26. Generic Server Cluster creation
   
   
3. After the generic server cluster is created, enter the connectivity information together with the weight for each cluster member. Figure 27 shows the configuration of a member of the generic server cluster. You need to specify the TCP/IP connectivity information in the form of hostname/IP-address and port together with a weight. The weight should not be zero, as a weight of zero means that no requests will be routed to this cluster member. In addition, the figure shows the matching configuration key directives from an IBM HTTP Server configuration.
   
   Figure 27. Generic Server Cluster member creation
   
   
4. Register every member of the generic server cluster in the generic server cluster definition. This enables the WebSphere proxy server to implement load balancing and fail-over capabilities among the cluster members:
   • The load balancing is a weighted round robin algorithm similar to the algorithm used by the web server plug-in.
   • As the members of the generic server cluster are only connected via HTTP or HTTPS, failure detection is limited by TCP/IP capabilities. Once the WebSphere proxy server determines a failure of one of the generic server cluster members, it periodically (every five seconds) checks if the server is available again by trying to establish a connection.
5. If you are using HTTPS protocol, you must ensure that the signer certificates of the unmanaged server's server certificates are in the trust store being used by the WebSphere proxy server. By default, this is the CellDefaultTrustStore in WebSphere Application Server V7.0 and later.

When you have finished these steps, the basic WebSphere configuration for generic server clusters is complete. For more details on configuring generic server clusters, see the WebSphere Application Server Information Center.
Routing configuration to generic server clusters
As the generic server cluster represents an unmanaged resource, WebSphere Application Server is not aware of any applications available via the generic server cluster. Therefore, manual configuration is required so that the proxy “knows” what requests to be forwarded to the generic server cluster.
For managed resources, routing decisions are based on the context root for the web modules that are enabled for proxy routing, as described earlier. To achieve the same for the unmanaged resources, you need to configure a URIgroup that basically provides the context root and a “Routing rule.” These two configuration items in WebSphere Application Server enable the proxy to make routing decisions for unmanaged resources.
Below are the minimum steps for the creation of a URIgroup and a routing rule:

The URI pattern used in the URI group definition must exist on each generic cluster member. This pattern is part of the request forwarded to the target server.

1. In the admin console of the cell hosting your WebSphere proxy server, navigate to Servers > Server types > WebSphere proxy servers > <proxy_name> < HTTP Proxy Server settings > Proxy settings > URI Groups > New. Figure 28 shows the configuration of a URI group that basically consists of a symbolic name and one or multiple URI patterns. Each request being processed by the WebSphere proxy sever is compared against these URI patterns to determine whether the request falls under that URI group.
   
   Figure 28. URI group definition screen
   
   
2. Once the URI group is configured, the routing must be explicitly configured so that the WebSphere proxy server knows where to route the requests . This again is done via the admin console by navigating to: Servers > Server types > WebSphere proxy servers > <proxy_name> > HTTP Proxy Server settings > Routing rules > New. Figure 29 shows the basic configuration of a routing rule for the proxy server. The rule is basically defined by specifying a symbolic name and selecting the WebSphere virtual host and URI group for which this rule applies. Under routing action, select the radio button for Generic Server Cluster, and then select the generic server cluster from the drop down box. Make sure that the check-box for Enable this rule is selected.
   
   
   Figure 29. Routing rule configuration screen
   
   
3. Restart the WebSphere proxy server.
4. Test the access to the unmanaged resource by sending a request that matches the URI pattern of the URI group definition.

See the WebSphere Application Server Information Center for more details on the routing rule configuration for the WebSphere proxy server.

---

Back to top

Conclusion
This article discussed the various resource categories that can be used by the WebSphere proxy server and the routing capabilities that the WebSphere proxy server provides. Detailed instructions for a sample topology were presented to highlight dependencies and possible problems in a several configuration scenarios. Hopefully, this information will help you quickly implement any of the given scenarios with success.

---

Back to top

Acknowledgments
The author thanks Tim Blank, Marie Gann, Kevin Kelle, John T. Pape, Ying Wang, and Bill Wigger for their valuable input during the creation of this article.

Resources

• Proxy server versus the HTTP plug-in: Choosing the best WebSphere Application Server workload management option
  
• Super cluster to the rescue, Part 1: Techniques to achieve extreme application scalability
  
• Super cluster to the rescue, Part 2: Maximum scalability using WebSphere DMZ Secure Proxy Server, ODR, and WebSphere eXtreme Scale
  
• Setting up the proxy server
  
• Configuring core groups
  
• Configuring the core group bridge service
  
• Top 10 FAQs on core group bridges
  
• Lightweight Third Party Authentication
  
• Single sign-on for authentication using LTPA cookies
  
• IBM WebSphere Application Server Information Center
  
• IBM developerWorks WebSphere