Chapter 1 Portal Server Architecture

Portals provide the user with a single point of access to a wide variety of content, data, and services throughout an enterprise. The content displayed through portal providers, channels, and portlets on the portal page can be personalized based on user preferences, user role or department within an organization, site design, and marketing campaigns for customers as end-users.

Portals serve as a simple, unified access point to web applications. Portals also do much more—they provide valuable functions like security, search, collaboration, and workflow. A portal delivers integrated content and applications, plus a unified, collaborative workplace. Indeed, portals are the next-generation desktop, delivering e-business applications over the web to all kinds of client devices. A complete portal solution should provide users with convenient access to everything they need to get their tasks done—any time, anywhere, in a secure manner.

Types of Portals

With many new portal products being announced, the marketplace has become very confusing. Indeed, any product or application that provides a web interface to business content could be classified as a portal. For this reason portals come in many flavors and have many different uses. They could be classified as one of the following:

Collaborative Portals

Business Intelligence Portals

Collaborative Portals

Collaborative portals help business users organize, find, and share unstructured office and groupware content—for example, e-mail, discussion group material, office documents, forms, memos, meeting minutes, web documents, and some support for live feeds. They differ from Internet and intranet portals not only in supporting a wider range of information, but also by providing a rich set of content management and collaborative services.

Content management services include text mining and clustering of related unstructured information, information categorization to classify it and make it easy to find, summarization to generate abstracts for documents, publish and subscribe, finding people, and tracking expertise.

Collaborative services allow users to chat, organize meetings, share calendaring information, define user communities, participate in net meetings, and share information in discussion groups and on white boards. Collaborative portals are mainly used internally as a corporate facility.

Business Intelligence Portals

Business intelligence portals provide executives, managers, and business analysts with easy access to business intelligence for making key business decisions. This type of portal typically indexes business intelligence reports, analyses, and canned queries, and are associated with financial management, customer relationship management, and supply chain performance management. They also provide seamless access to business intelligence tools (reporting, OLAP, data mining), and packaged analytic applications. They also support alerting, publishing and subscribing. Peoplesoft is a typical vendor provider of business intelligence types of portal.

Procurement portal

Self-service portal

Business portal

e-Commerce portal

Sales support

Customer relationship management, operations, and employee portals

Consumer portal

Portal Server Capabilities

Sun Java™ System Portal Server 6 2004Q2 software (formerly Sun ONE Portal Server) provides the following capabilities to your organization:

Secure access and authorized connectivity, optionally using encryption between the user’s browser and the enterprise

Authentication of users before allowing access to a set of resources that are specific for each user

Support for abstractions that provide the ability to pull content from a variety of sources and aggregate and personalize it into an output format suitable for the user’s device

A search engine infrastructure to enable intranet content to be organized and accessed from the portal

Ability to store user- and service-specific persistent data

Access to commonly needed applications for accessing services such as mail, calendar, and file storage

An administration interface enabling delegated and remote administration

Single sign-on and security features, enabling standard access to enterprise applications and content

Personalization through the use of portal providers, portlet and web service remote portlet (WSRP).

Publishing and managing content (provided by third-party applications such as FatWire, pCM )

Sun Java System Portal Server

Portal Server is a component of the Sun Java™ Enterprise System. Sun Java Enterprise System is a software system that supports a wide range of enterprise computing needs, such as creating a secure intranet portal to provide the employees of an enterprise with secure access to email and in-house business applications.

The Portal Server product is an identity-enabled portal server solution. It provides all the user, policy, and identity management to enforce security, web application single sign-on (SSO), and access capabilities to end user communities. In addition, Portal Server combines key portal services, such as personalization, aggregation, security, integration, and search. Unique capabilities that enable secure remote access to internal resources and applications round out a complete portal platform for deploying robust business-to-employee, business-to-business, and business-to-consumer portals. The Sun Java™ System Portal Server Secure Remote Access (SRA) (formerly Sun ONE Portal Server, Secure Remote Access) product provides additional secure remote access capabilities to access web- and non-web enabled resources.

Each enterprise assesses its own needs and plans its own deployment of Java Enterprise System. The optimal deployment for each enterprise depends on the types of applications that Java Enterprise System is supporting, the number of users, the kind of hardware that is available, and other considerations of this type.

Portal Server is able to work with previously installed software components. In this case, Portal Server uses the installed software as long as the software is an appropriate version.

Sun Java System Secure Remote Access

Sun Java System Portal Server Secure Remote Access (SRA) offers browser-based secure access to portal content and services from any remote browser enabled with Java technology.

SRA is a cost-effective, secure access solution that is accessible to users from any Java™ technology-enabled browser, eliminating the need for client software. Integration with Portal Server software ensures that users receive secure encrypted access to the content and services that they have permission to access.

SRA is targeted toward enterprises deploying highly secure remote access portals. These portals emphasize security, protection, and privacy of intranet resources. The SRA services–the Gateway, NetFile, Netlet, and Proxylet– enable users to securely access intranet resources through the Internet without exposing these resources to the Internet.

Portal Server runs in open mode and secure mode, that is, either without SRA or with SRA.

Portal Sever in Open Mode

In open mode, Portal Server is installed without SRA. The typical public portal, such as my.yahoo, runs without secure access using only the HTTP protocol. Although you can configure Portal Server to use the HTTPS protocol in open mode (either during or after installation), secure remote access is not possible. This means that users cannot access remote file systems and applications.

The main difference between an open portal and a secure portal is that the services presented by the open portal typically reside within the demilitarized zone (DMZ) and not within the secured intranet.

If the portal does not contain sensitive information (deploying public information and allowing access to free applications), then responses to access requests by a large number of users is faster than secure mode.

Figure 1-1 shows Portal Server configured for open mode. In this figure, Portal Server is installed on a single server behind the firewall. Multiple clients access the Portal Server system across the Internet through the single firewall, or from a web proxy server that sits behind a firewall.



Note	You can provide secure access to users of web-enabled resources by running Portal Server in open mode with the HTTPS protocol. However, without SRA, you cannot provide secure remote access to file systems or TCP/IP applications.

Portal Server in Secure Mode

In secure mode, Portal Server is installed with SRA. Secure mode provides users with secure remote access to required intranet file systems and applications.

The main advantage of SRA is that only the IP address of the Gateway is published to the Internet. All other services and their IP addresses are hidden and never published to a Domain Name Service (DNS) that is running on the public network (such as the Internet).

The Gateway resides in the demilitarized zone (DMZ). The Gateway provides a single secure access point to all intranet URLs and applications, thus reducing the number of ports to be opened in the firewall. All other Sun Java System services such as Session, Authentication, and Portal Desktop, reside behind the DMZ in the secured intranet. Communication from the client browser to the Gateway is encrypted using HTTP over Secure Sockets Layer (HTTPS). Communication from the Gateway to the server and intranet resources can be either HTTP or HTTPS.

Figure 1-2 shows Portal Server installed with SRA. SSL is used to encrypt the connection between the client and the Gateway over the Internet. SSL can also be used to encrypt the connection between the Gateway and the Portal Server system. The presence of a Gateway between the intranet and the Internet extends the secure path between the client and the Portal Server system.

You can add additional servers and Gateways for site expansion. You can also configure the components of SRA in various ways based on your business requirements.

Security, Encryption, and Authentication

Portal Server system security relies on the HTTPS encryption protocol, in addition to UNIX system security, for protecting the Portal Server system software.

Security is provided by the web container, which you can configure to use SSL, if desired. Portal Server also supports SSL for authentication and end-user registration. By enabling SSL certificates on the web server, the Portal Desktop and other web applications can also be accessed securely. You can use the Identity Server policy to enforce URL-based access policy.

Portal Server depends on the authentication service provided by Sun Java System Identity Server and supports single sign-on (SSO) with any product that also uses the Identity Server SSO mechanism. The SSO mechanism uses encoded cookies to maintain session state.

Another layer of security is provided by SRA. It uses HTTPS by default for connecting the client browser to the intranet. The Gateway uses Rewriter to enable all intranet web sites to be accessed without exposing them directly to the Internet. The Gateway also provides URL-based access policy enforcement without having to modify the web servers being accessed.

Communication from the Gateway to the server and intranet resources can be HTTPS or HTTP. Communication within the Portal Server system, for example between web applications and the directory server, does not use encryption by default, but it can be configured to use SSL.

Portal Server Deployment Components

Sun Java™ System Identity Server software

Sun Java System Identity Server provides user and service management, authentication and single sign-on services, policy management, logging service, debug utility, the administration console, and client support interfaces for Portal Server. This consists of:

Java™ Development Kit (JDK™)--Java Development Kit provides the Java run-time environment for all Java software in Portal Server and its underlying components. Portal Server depends on the JDK of the web container.

Network Security Services for Java™

Sun Java™ System Web Server (JSS),

Java™ API for XML Processing (JAXP),

Sun Java™ System Directory Server software

Web Containers

Sun Java™ System Web Server

Sun Java™ System Application Server

The following web containers can be used in place of the Sun Java™ System Web Server and Sun Java™ System Application Server software:

BEA WebLogic Server™

IBM WebSphere® Application Server

See the Sun Java System Installation Guide for information on deploying Portal Server in various web containers.


Note	See the Portal Server 6 Release Notes for specific versions of products supported by Portal Server.

Portal Server Architecture

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 server where Portal Server resides, Sun Java System Web Server or other web container. You can also install the Search component on this node if desired. Identity Server can reside here.

Identity Server node—The server where Identity Server can reside. Identity Server 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 upon which you install the SRA Gateway. You can also install the Gateway on the portal node, though in general, because you locate the Gateway in the DMZ, it will be on a separate, non-portal node.

Netlet Proxy node—Optional. The node used to run applications securely between users’ remote desktops and the servers running applications on your intranet.

Rewriter Proxy node—Optional. The node used to run applications securely between users’ remote desktops and the servers running applications on your intranet.

Directory Server—The server running Sun Java System Directory Server software. You can install Directory Server on a separate node.

Other servers—These servers, such as mail, file, and legacy servers, provide backend support, data, and applications to portal users.

Identity Management

Portal Server uses identity management to control many users spanning a variety of different roles across the organization and sometimes outside the organization while accessing content, applications and services. The challenges include: Who is using an application? In what capacity do they serve the organization or company? What do they need to do, and what should they be able to access? How can others help with the administrative work?

Java APIs used to access SSO Token, user profiles, logging, and debugging

Command line tools such as amadmin, amserver, and ampassword

Web application services such as session, authentication, logging, and naming

Administration console web application

Identity Server SDK

Identity Server console SDK

Authentication daemons that support the web applications

Portal Server Software Deployment

This section provides information on software deployed in Portal Server. It provides information on the software packaging mechanism, the software categories within the system, and the Java compatibility of the software.

Software Packaging

Portal Server uses a “dynamic WAR file” approach to deploy software to the system. Portal Server is installed using Solaris™ packages, which consist of individual files that comprise web applications, for example, JAR, JSP, template, and HTML files. The packages do not contain WAR or EAR files. The packages do contain web.xml fragments that are used to construct the Portal Server WAR file at installation time. This dynamically constructed file is then deployed to the web application container. As additional packages are added to the system, for example, for localization, the web application file is rebuilt and redeployed.



Note	The WAR file packaging and deployment mechanism is for use only by Sun Java System Portal Server products. Customer modifications to the WAR file or any files used to build it are currently not supported.

Software Categories

Portal Server distinguishes between the following kinds of software that it installs onto the Portal Server node:

Dynamic web applications—Includes Java servlets, JSP files, content providers, and other items that the Java web container processes when accessed by the user’s browser. For Portal Server, these files are installed in the web server.

Static web content—Includes static HTML files, images, applet JAR files, and other items that can be served up directly by the web server without using the Java web container. For Portal Server, these files are also installed in the web server.



Note	Static web content and dynamic web applications are all grouped together into a single WAR file.

Configuration data—Includes data that is installed into the directory, that is, the Identity Server service definitions and any other data that modifies the directory at installation time. This includes modifications to the console configuration data to connect in the Portal Server extensions. Configuration data is installed only once no matter how many Portal Server nodes there are.

SDK—This is the JAR file or files that contain the Java APIs that are made available by a component. Developers need to install this package on a development system so that they can compile classes that use the API. If a component does not export any public Java APIs, it would not have this package.

Java Compatibility

Applets—Applets used in Portal Server are compatible with Java 1.1, which is supported by most browsers.

Web applications—Web applications are intended to be compatible with the J2EE™ web container based on the servlets interface except where uses of special interfaces are identified. This includes compatibility with Java 2 and later.

Stand-alone Java processes—Stand-alone Java processes are compatible with Java 2 and later. Some Portal Server software, specifically in SRA, use JNI to call C APIs. These calls are necessary to enable the system to run as the user nobody.

A Typical Portal Server Installation

Figure 1-3 illustrates some of the components of a portal deployment but does not address the actual physical network design, single points of failure, nor high availability. See Chapter 5, "Creating Your Portal Design", for more detailed information on portal design.

This illustration shows the high-level architecture of a typical installation at a company site for a business-to-employee portal. In this figure, the Gateway is hosted in the company’s DMZ along with other systems accessible from the Internet, including web servers, proxy/cache servers, and mail Gateways. The portal node, portal search node, and directory server, are hosted on the internal network where they have access to systems and services ranging from individual employee desktop systems to legacy systems.



Note	If you are designing an ISP hosting deployment, which hosts separate Portal Server instances for business customers who each want their own portal, contact your Sun Java System representative. Portal Server requires customizations to provide ISP hosting functionality.

In Figure 1-3, users on the Internet access the Gateway from a browser. The Gateway connects the user to the IP address and port for the portal they are attempting to access. For example, a B2B portal would usually allow access to only port 443, the HTTPS port. Depending on the authorized use, the Gateway forwards requests on to the portal node, or directly to the service access on the enterprise internal network.

Previous Contents Index Next
Sun Java System Portal Server 6 2004Q2 Deployment Planning Guide