Choosing Security Strategies for the SunWeb Architecture

The requirements for the SunWeb portal service posed the following security challenges:

• First, each employee's access must be limited to the services and data channels that he or she is authorized to view.

• Second, the SunWeb portal service must allow Sun employees secure remote access to SunWeb services and data channels over the public Internet while preventing unauthorized people from accessing the portal.

For more information on the security requirements, see Security Requirements.

The SunWeb architects met the first challenge by including Access Manager and Directory Server in the deployment to control employee access to portal content. These Access Manager and Directory Server instances are separate from the main corporate LDAP service. The SunWeb directory service is dedicated to maintaining each employee's portal desktop profile. The desktop profile includes any desktop customization performed by the employee, as well as LDAP attributes and object classes that determine what content an employee is authorized to view. For more information on this aspect of the deployment, see The LDAP Schema.

The SunWeb architects met the second challenge by including the Portal Server Secure Remote Access component and its gateway service in the deployment and by designing network access zones that take maximum advantage of the gateway service. The access zones are demarcated by firewalls. The access zones and the firewalls are represented in Figure 3–4.

The outermost zone in Figure 3–4 is the demilitarized zone (DMZ), which contains the portal gateway. The DMZ is reasonably secure. The portal gateway service behind the firewall can be accessed at one specific URL only. Employees who connect to the SunWeb portal with remote web browser clients or mobile clients access the gateway service at the specified URL. The firewall blocks all other ports and addresses.

In addition to deploying the gateway service behind Firewall 3 in the DMZ, the SunWeb architecture protects the gateway service in the following ways:

• The gateway service requires users to authenticate themselves. Employees who open the URL for the gateway service in their web browsers are presented with a login page. Employees must enter a user ID and a dynamically generated password to gain access to any content.

• The computers that provide the gateway service are behind a hardware load balancer. The load balancer provides a single point of contact for the gateway service, even though multiple component instances are running on multiple computers. As a result, there is only one opening in the firewall for the gateway service, and all of the traffic for the gateway service is routed through the load balancer.

• Not shown in Figure 3–4, but implied in the deployment architecture, is a network topology that creates separate subnets for each of the access zones. The IP addresses used in the subnets are private IP addresses, making the subnets invisible to the public Internet. These subnets are connected only through the load balancers, further impeding the ability of intruders to see the actual computers behind the public URL. For more information on the network topology, see Preparing the Network and Connectivity Specification.

The next zone, behind Firewall 2, is the SunWeb subnet. This zone contains the actual SunWeb portal service, which is provided by eight instances of Portal Server, supported by eight instances of Access Manager and two instances of Directory Server. This zone is defined by an additional firewall (Firewall 2).

In addition to deploying the portal service on its own subnet behind Firewall 2, the SunWeb architecture protects the portal service in the following ways:

• Remote access to the portal service from the public Internet is controlled by the Portal Server SRA gateway service in the DMZ. All remote access to the portal service is through the gateway service. This aspect of the architecture allows the portal service to reside behind an additional firewall and an additional layer of hardware load balancing.

• The load balancer behind Firewall 2 provides a single point of contact for the portal service, even though the service consists of eight Portal Server instances that are running on eight computers. The load balancer is the only opening in the firewall for the portal service, and all of the traffic for the portal service is routed through the load balancer. Employees connected to the main corporate network also access the SunWeb portal through this load balancer.

• Local access to the portal service is only from trusted computers on the main corporate network after users have authenticated themselves to the corporate LDAP directory service.

• The computers running Portal Server and Access Manager are on a different subnet from the computers in the DMZ, and this subnet is defined by private IP addresses. The only bridge between the subnets is the hardware load balancer.

The main corporate network contains various corporate information services that are accessed by the SunWeb portal service. These services are protected by Firewall 1. In addition to Firewall 1, the main corporate network is protected by the following measures:

• There is no direct remote access to these corporate services. All remote access is indirect, through the Portal Server instances.

• The CMS only allows traffic from the PCD instances that are colocated with the Portal Server instances. All other traffic is blocked.

Not shown in Figure 3–4 is the fact that the individual computers running the Java ES services are hardened.