Sun Java System Portal Server 7 Deployment Planning Guide

Portal Server Nodes

Usually, but not always, you deploy Portal Server software on the following different portal nodes (servers) that work together to implement the portal:

Portal Server node. The web server where Portal Server resides. You can also install the Search component on this node if desired. Access Manager can reside here.
Access Manager node.The server where Access Manager can reside. Access Manager does not have to reside on the same node as Portal Server.
Search node. Optional. The server you use for the Portal Server Search service. You can install the Portal Server Search service on its own server for performance, scalability and availability reasons.
Gateway nodes. Optional. The server where the SRA Gateway resides. You can install the Gateway on the portal node. Because you locate the Gateway in the DMZ, the Gateway is installed on a separate, non-portal node.
Netlet Proxy node. Optional. The server used to run applications securely between users’ remote desktops and the servers running applications on your intranet.
Rewriter Proxy node. Optional. The server used to run applications securely between users’ remote desktops and the servers running applications on your intranet.
Directory Server node. The server running Directory Server software. You can install Directory Server on a non-portal node.
Other servers. These servers, such as mail, file, and legacy servers, provide backend support, data, and applications to portal users.

Portal Server and Access Manager on Different Nodes

Portal Server and Access Manager can be located on different nodes. This type of deployment provides the following advantages:

Identity services can be deployed separately from portal services. Portal Server can be one of many applications using identity services.
Authentication and policy services can be separate from provider applications including Portal Server related applications.
Access Manager can be used by other web containers to assist with development of portal customizations.

Note –

When Portal Server and Access Manager are on different nodes, the Access Manager SDK must reside on the same node as Portal Server. The web application and supporting authentication daemons can reside on a separate node from the Portal Server instance.

The Access Manager SDK consists of the following components:

Identity Management SDK–provides the framework to create and manage users, roles, groups, containers, organizations, organizational units, and sub-organizations.

Authentication API and SPI–provides remote access to the full capabilities of the Authentication Service.

Utility API–manages system resources.

Loggin API and SPI–records, among other things, access approvals, access denials and user activity.

Client Detection API–detects the type of client browser that is attempting to access its resources and respond with the appropriately formatted pages.

SSO API–provides interfaces for validating and managing session tokens, and for maintaining the user’s authentication credentials.

Policy API–evaluates and manages Access Manager policies and provides additional functionality for the Policy Service.

SAML API–exchanges acts of authentication, authorization decisions and attribute information.

Federation Management API–adds functionality based on the Liberty Alliance Project specifications.

Portal Server System Communication Links

Figure 4–1 shows the processes and communication links of a Portal Server system that are critical to the availability of the solution.

Figure 4–1 Portal Server Communication Links

This figure contains a Portal Server Instance with five servlets
and three SDKs and shows how they communicate with each other.

In this figure, the box encloses the Portal Server instance running on Web Server technology. Within the instance are five servlets (Authentication, Portal Server administration console, Portal Desktop, Communication Channel, and Search), and the three SDKs (Access Manager SSO, Access Manager Logging, and Access Manager Management). The Authentication service servlet also makes use of an LDAP service provider module.

A user uses either a browser or the Gateway to communicate with Portal Server. This traffic is directed to the appropriate servlet. Communication occurs between the Authentication service’s LDAP module and the LDAP authentication server; between the Communications channel servlet and the SMTP/IMAP messaging server; between the Access Manager SSO SDK and the LDAP server; and between the Access Manager Management SDK and the LDAP server.

Figure 4–1 shows that if the following processes or communication links fail, the portal solution becomes unavailable to end users:

Portal Server Instance. Runs in the context of a web container. Components within an instance communicate through the JVM using Java^TM APIs. An instance is a fully qualified domain name and a TCP port number. Portal Server services are web applications that are implemented as servlets or JSP^TM files

Portal Server is built on top of Access Manager for authentication single sign-on (session) management, policy, and profile database access. Thus, Portal Server inherits all the benefits (and constraints) of Access Manager with respect to availability and fault tolerance.

By design, Access Manager’s services are either stateless or the services can share context data. Services can recover to the previous state in case of a service failure.

Within Portal Server, Portal Desktop does not share state data among instances. This means that an instance redirect causes the user context to be rebuilt for the enabled services. Usually, redirected users do not notice this because Portal Server services can rebuild a user context from the user’s profile, and by using contextual data stored in the request. While this statement is generally true for out-of-the-box services, it might not be true for channels or custom code. Developers need to be careful to not design stateful channels to avoid loss of context upon instance failover.
Profile Database Server. The profile database server is implemented by Directory Server software. Although this server is not strictly part of Portal Server, availability of the server and integrity of the database are fundamental to the availability of the system.
Authentication Server. This is the directory server for LDAP authentication (usually, the same server as the profile database server). You can apply the same high availability techniques to this server as for the profile database server.
SRA Gateway and Proxies . The SRA Gateway is a standalone Java technology process that can be considered stateless, because state information can be rebuilt transparently to end users. The Gateway profile maintains a list of Portal Server instances and does round robin load balancing across the Gateway instances. Session stickiness is not required in front of a Gateway, but with session stickiness, performance is better. On the other hand, session stickiness to Portal Server instances is enforced by SRA.

SRA includes other Java technology processes called Netlet Proxy and Rewriter Proxy. You use these proxies to extend the security perimeter from behind the firewall, and limit the number of holes in the DMZ. You can install these proxies on separate nodes.