|
| |
| Sun Java System Portal Server 6 2005Q4 Deployment Planning Guide | |
Chapter 1
Portal Server ArchitectureThis chapter contains the following sections:
What is a Portal?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 unified access point to web applications. Portals also 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 access to everything users need to get their tasks done—any time, anywhere, in a secure manner.
Types of PortalsWith 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 have many different uses and can be classified as one of the following:
Collaborative Portals
Collaborative portals help business users organize, find, and share unstructured office content—for example, e-mail, discussion group material, office documents, forms, memos, meeting minutes, web documents, and some support for live feeds. Collaborative portals differ from Internet and intranet portals not only in supporting a wider range of information, but also by providing a set of content management and collaborative services.
Content management services include the following:
Collaborative portals are mainly used internally as a corporate facility.
Collaborative services allow users to do the following:
Business Intelligence Portals
Business intelligence portals provide executives, managers, and business analysts with access to business intelligence for making business decisions. This type of portal typically indexes business intelligence reports, analyses, and predefined queries, and are associated with financial management, customer relationship management, and supply chain performance management. Business intelligence portals also provide access to business intelligence tools (reporting, OLAP, data mining), packaged analytic applications, alerting, publishing and subscribing. Peoplesoft is a typical vendor provider of business intelligence types of portal.
Types of business intelligence portals include:
Portal Server CapabilitiesSun Java™ System Portal Server 6 2005Q4 software 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.
- Publishing and managing content (provided by third-party applications such as FatWire)
Sun Java System Portal ServerPortal Server is a component of the Sun Java™ Enterprise System technology. Sun Java Enterprise System technology 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 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 business-to-employee, business-to-business, and business-to-consumer portals. The Sun Java System Portal Server Secure Remote Access (SRA) 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 technology. The optimal deployment for each enterprise depends on the type of applications that Java Enterprise System technology supports, 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 when the software is an appropriate version.
Secure Remote AccessSun 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 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 users 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–Access List, 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 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.
Figure 1-1 Portal Server in Open Mode
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 (SSL). 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.
Figure 1-2 Portal Server in Secure Mode
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 AuthenticationPortal 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 Access Manager policy to enforce URL-based access policy.
Portal Server depends on the authentication service provided by Sun Java System Access Manager and supports single sign-on (SSO) with any product that also uses the Access Manager 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 ComponentsPortal Server deployment consists of the following components:
Access Manager 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 software provides the Java run-time environment for all Java software in Portal Server and its underlying components. Portal Server depends on the JDK software in the web container.
- Network Security Services for Java software
- Sun Java System Web Server
- Java API for XML Processing (JAXP),
Note
See the Portal Server 6 Release Notes for specific versions of products supported by Portal Server.
Portal Server ArchitectureUsually, 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.
Identity ManagementPortal Server uses the Access Manager 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 users serve the organization or company? What do users need to do, and what should users be able to access? How can others help with the administrative work?
Access Manager software consists of the following components:
- Java software 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
- Access Manager SDK
- Access Manager console SDK
- Authentication daemons that support the web applications
See the Access Manager Deployment Planning Guide for more information.
Portal Server Software DeploymentThis section provides information on software deployed on Portal Server.This section provides information on the software packaging mechanism, the software categories within the system, and compatibility with Java 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 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. These include servlets running on a Java platform, JSP files, content providers, and other items that the web container processes when accessed by the user’s browser. For Portal Server, these files are installed in the Web Server.
- Static web content. These include static HTML files, images, applet JAR files, and other items that can be served up directly by the web server without using the Web Server 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. These include data that is installed into the directory, that is, the Access Manager 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.
A Typical Portal Server InstallationFigure 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 proxy/cache servers, web servers, and mail Gateways. The portal node, portal search node, and directory server, are hosted on the internal network where users have access to systems and services ranging from individual employee desktop systems to legacy systems.
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 users 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 to the portal node, or directly to the service on the enterprise internal network.
Figure 1-3 High-level Architecture for a Business-to-Employee Portal
Figure 1-4 shows a Portal Server deployment with SRA services. See Chapter 2, "Portal Server Secure Remote Access Architecture" for details.
Figure 1-4 SRA Deployment
