The security requirements of the portal service reference configuration (see Security Requirements) are met through several mechanisms, each of which are discussed in the following sections:
Each user's access must be limited to the portal services and data channels that he or she is authorized to view.
The reference configuration uses Access Manager and Directory Server to control user access to portal content. The directory service maintains each user's portal desktop profile. This profile includes any desktop customization that is performed by the user, as well as mechanisms for determining what content the user is authorized to view.
The modularized architecture makes it easy for different organizations to administer different service modules so that each organization has the level of administrative security it needs. In most enterprises, for example, directory services and Access Manager services are administered by security-oriented organizations, while portal services are administered by end-user applications organizations.
The portal service must be secured against unauthorized and unauthenticated access.
The deployment architecture uses a secure network topology for the portal service, which includes the use of firewalls, controlled access through load balancers with virtual service addresses, and private subnets behind the firewall.
Figure 2–2 shows a portal services zone in which the portal service, Access Manager service, and directory service modules are deployed behind the Internal Firewall. Within this zone, the deployment architecture protects the service modules in the following ways:
A load balancer provides a single point of contact for the portal service, even though the service consists of two Portal Server instances that are running on two computers. This means that there is only one opening in the firewall for the portal service, and all of the traffic for the portal service is routed through the load balancer. Note that employees connected to the main corporate network also access the portal through this load balancer.
Local access to the portal service is only from trusted computers on the corporate network, by users who have authenticated themselves to the corporate network.
Not shown in Figure 2–2, but implied in the deployment architecture, is a network topology that creates separate subnets for accessing each service module. The IP addresses that are used in the subnets are private IP addresses, making the subnets invisible to the outside world. These subnets are connected only through the load balancers, further impeding the ability of intruders to access the actual computers behind the public URL. For more information on the network topology, see Network Connectivity Specification.
Not shown in Figure 2–2 is that the individual computers hosting service instances are hardened and that the operating system installations are minimized. Minimizing the number of installed Solaris OS packages means fewer security holes. Because the majority of system penetrations are through exploitation of operating system vulnerabilities, minimizing the number of installed operating system packages will reduce the number of vulnerabilities. Minimizing the operating system is covered in detail in Computer Hardware and Operating System Specification.
The secure remote access option provides secure access to portal services, applications, and other content on an internal intranet to employees or customers on the public Internet. This option prevents such access to unauthorized people.
The requirement for secure remote access is met in the Portal Service on Application Server Cluster reference configuration through Portal Server SRA components, specifically the SRA Gateway service, and by network access zones, demarcated by firewalls, that take maximum advantage of the SRA Gateway service. The access zones and the firewalls are represented in Figure 2–2.
The outermost zone in Figure 2–2 is the so-called demilitarized zone, or DMZ, which contains the SRA Gateway service. The Gateway service can only be accessed through the External Firewall at one specific URL. Employees or customers who connect to the portal service with remote browser clients or mobile clients do so by accessing the Gateway service at the specified URL. The External Firewall blocks all other ports and addresses.
Because remote access to the portal service from the public Internet is through the Gateway service, the portal service itself can reside behind an additional firewall (the Internal Firewall) and an additional layer of hardware load balancing.
In addition to deploying the Gateway service behind an Internet-facing firewall, the deployment architecture secures the Gateway service in the following ways:
The Gateway service requires the authentication of all users. Users who access the URL for the Gateway service in their browsers are presented with a login page and must type a user ID and password to gain access to any content.
The Gateway service instances 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, only one port in the firewall is needed for the Gateway service, and all requests are routed through the load balancer.
The communication between the browser and the Gateway service load balancer is encrypted through using the SSL protocol. This protocol is required because this traffic will circulate through an unsecured network (the Internet). The SSL protocol also requires the use of server certificates to ensure that service providers have not been tampered with. Optionally, client certificates can be used to better authenticate access to the Gateway service.