test

Sun Java System Reference Configuration Series: Portal Service on Application Server Cluster

Network Connectivity Specification

Before you can install and configure Java ES components, the computers that you are using must be assigned IP addresses and attached to your network. The network topology for the portal service reference configuration uses several subnets with different ranges of IP addresses for each subnet. A network connectivity specification shows the network connections and the IP addresses that are needed to implement the reference configuration.

A network connectivity specification is typically a graphical representation of the required network configuration. The following figure shows the specification for the Portal Service on Application Server Cluster reference configuration. In the specification, all computers are shown in a pstest.com domain and are assigned the IP addresses that are used to establish the required network topology.

Note –

The procedures in this guide use the host names, domain name, and IP addresses shown in Figure 3–1. However, you must map these host names, domain name, and IP addresses to equivalent names and addresses in your environment. For this reason, the procedures in this guide show host names, domain name, and IP addresses as variables.

Figure 3–1 Network Connectivity Specification for the Reference Configuration Deployment

Graphic representation of the network connectivity specification, showing three networks, as described in the text.

This figure illustrates how the different modules in the architecture are connected. Each module consists of two component instances, as well as a load balancer that provides a single entry point for the module. Each load balancer is configured to provide a virtual service address that accepts all requests for its respective service. The load balancer is configured to route such requests among the component instances in the module.

Portal Service Subnet

In Figure 3–1, the directory, Access Manager, and portal service modules reside in a network zone that is isolated from the main corporate network. Within this zone are separate subnets that are used to help secure each service.

Each service is accessed only through its respective load balancer. Clients of the service address their requests to the virtual IP address that is configured into the load balancer. Behind the load balancer, the computers that are running the component instances are isolated on their own subnets with private IP addresses. In Figure 3–1, the following five subnets are used:

The directory service load balancer is on the same subnet as the Access Manager and Portal Server instances because the latter directly access directory services.

These subnets are bridged by the load balancers, and all communications between the subnets is routed through routers. Therefore, if one subnet is compromised, there is no direct route to other services.

Gateway Service Subnet

The Gateway service runs in a separate subnet (the DMZ) that is isolated from the portal service subnet by an Internal Firewall and from the public Internet by an External Firewall, as shown in Figure 3–1.

In the DMZ, only the Gateway service load balancer (at sra.pstest.com) is exposed to traffic from the public Internet, and only through the External Firewall. Other hardware in the DMZ is assigned a private IP address, in keeping with the philosophy of minimizing the surface of attack. In Figure 3–1, the DMZ subnet is created with private IP addresses in the 10.0.4.0/24 range. These private addresses are not recognized by the Internet and are not routed outside the network.

Note –

In Figure 3–1, the gateway service load balancer is shown with the IP address 10.0.5.10. When you deploy your reference configuration, you must configure this load balancer with a real, publicly accessible IP address that is appropriate for your site.

The firewall rules that are used to establish the Gateway service subnet are shown in the following tables.

Table 3–2 Internal Firewall Rules

Rule Number 

Source 

Destination 

Type/Port 

Action 

1 

sra1.pstest.com

sra2.pstest.com

am.pstest.com

TCP/80 

ALLOW 

2 

sra1.pstest.com

sra2.pstest.com

ps.pstest.com (Portal Server)

TCP/80 

ALLOW 

3 

sra1.pstest.com

sra2.pstest.com

ps.pstest.com (Rewriter Proxy)

TCP/10433 

ALLOW 

4 

sra1.pstest.com

sra2.pstest.com

ps.pstest.com (Netlet Proxy)

TCP/10555 

ALLOW 

5 

am1.pstest.com

am2.pstest.com

sra1.pstest.com

sra2.pstest.com

TCP/443 

ALLOW 

6 

* 

* 

* 

DENY 

The first two rules in the previous table allow the Gateway instances to reach the virtual service IP addresses (the load balancers) for the Access Manager and portal services. Rule 3 allows the session notifications that are generated by the Access Manager instances to reach the Gateway instances. The firewall automatically adds rules to allow the response traffic.

Table 3–3 External Firewall Rules

Rule Number 

Source 

Destination 

Type/Port 

Action 

1 

* 

sra.pstest.com

TCP/443 

ALLOW 

2 

* 

* 

* 

DENY 

The rules in the previous table allow only the Gateway service load balancer to be accessed from the Internet.

DNS Considerations

In implementing a network connectivity specification, you must coordinate the setting of virtual service IP addresses with the configuration of your DNS servers (or whatever naming service your network is using). Doing so ensures that the correct service names and IP addresses are routed publicly. In Figure 3–1, the externally accessible DNS server maps the URL www.pstest.com to the virtual service IP address for the Gateway service load balancer. For example, the internal DNS server maps the host name sra.pstest.com to the same virtual service address.

Other Networks

Figure 3–1 also shows two additional networks that are often used to implement a deployment architecture: