Sun Java System Portal Server 6 2004Q2 Deployment Planning Guide |
Chapter 5
Creating Your Portal DesignThis chapter describes how to create your high-level and low-level portal design and provides information on creating specific sections of your design plan.
This chapter contains the following sections:
Portal Design ApproachAt this point in the Portal Server deployment process, you’ve identified your business and technical requirements, and communicated these requirements to the stakeholders for their approval. Now you are ready to begin the design phase, in which you develop your high- and low-level designs.
Your high-level portal design communicates the architecture of the system and provides the basis for the low-level design of your solution. Further, the high-level design needs to describe a logical architecture that meets the business and technical needs that you previously established. The logical architecture is broken down according to the various applications that comprise the system as a whole and the way in which users interact with it. In general, the logical architecture includes Sun Java System Portal Server Secure Remote Access (SRA) , high availability, security (including Sun Java System Identity Server, and Sun Java System Directory Server (formerly Sun ONE Directory Server) architectural components. See Logical Portal Architecture for more information.
The high- and low-level designs also need to account for any factors beyond the control of the portal, including your network, hardware failures, and improper channel design.
Once developed, the high-level design leads toward the creation of the low-level design. The low-level design specifies such items as the physical architecture, network infrastucture, Portal Desktop channel and container design and the actual hardware and software components. Once you have completed the high- and low-level designs, you can begin a trial deployment for testing within your organization.
Overview of High-Level Portal Design
The high-level design is your first iteration of an architecture approach to support both the business and technical requirements. The high-level design addresses questions such as:
- Does the proposed architecture support both the business and technical requirements?
- Can any modifications strengthen this design?
- Are there alternative architectures that might accomplish this?
- What is the physical layout of the system?
- What is the mapping of various components and connectivity?
- What is the logical definition describing the different categories of users and the systems and applications they have access to?
- Does the design account for adding more hardware to the system as required by the increase in web traffic over time?
Overview of Low-Level Portal Design
The low-level design focuses on specifying the processes and standards you use to build your portal solution, and specifying the actual hardware and software components of the solution, including:
- The Sun Java System Portal Server (formerly Sun ONE Portal Server)complex of servers.
- Network connectivity, describing how the portal complex attaches to the “outside world.” Within this topic, you need to take into account security issues, protocols, speeds, and connections to other applications or remote sites.
- Information architecture, including user interfaces, content presentation and organization, data sources, and feeds.
- Sun Java System Identity Server architecture, including the strategy and design of organizations, suborganizations, roles, groups, and users, which is critical to long-term success.
- Integration strategy, including how the portal acts as an integration point for consolidating and integrating various information, and bringing people together in new ways.
Logical Portal Architecture
Your logical portal architecture defines all the components that make up the portal, including (but not limited to) the following:
- Sun Java System Portal Server itself
- Contents from RDBMs
- Third-party content providers
- Custom developed providers and content
- Integration with back-end systems such as messaging and calendaring systems
- Web container for deployment
- Role of the Content Management System
- Customer Resource Management
- Whether the portal runs in open or secure mode (requires Sun Java System Secure Remote Access)
- Usage estimates, which include your assumptions on the total number of registered users, average percentage of registered users logged in per day, average concurrent users that are logged in per day, average login time, average number of content channels that a logged in user has selected, and average number of application channels that a logged in user has selected.
Additionally, you need to consider how the following three network zones fit into your design:
- Internet—The public Internet is any network outside of the intranet and DMZ. Users portal server and securely access the Gateway and from here.
- Demilitarized Zone (DMZ)—A secure area between two firewalls, enabling access to internal resources while limiting potential for unauthorized entry. The Gateway resides here where it can securely direct traffic from the application and content servers to the Internet.
- Intranet—Contains all resource servers. This includes intranet applications, web content servers, and application servers. The Portal Server and Sun Java System Directory Server reside here.
The logical architecture describes the Portal Desktop look and feel, including potential items such as:
- Default page, with its default banner, logo, channels; total page weight, that is, total number of bytes of all the components of the page, including HTML, style sheet, JavaScript, and image files; total number of HTTP requests for the page, that is, how many HTTP requests are required to complete downloading the page.
- Personalized pages, with channels that users can conceivably display and what preferences are available.
The logical architecture is where you also develop a caching strategy, if your site requires one. If the pages returned to your users contain references to large numbers of images, Portal Server can deliver these images for all users. However, if these types of requests can be offloaded to a reverse proxy type of caching appliance, you can free up system resources so that Portal Server can service additional users. Additionally, by placing a caching appliance closer to end users, these images can be delivered to end users somewhat more quickly, thus enhancing the overall end user experience.
Portal Server and ScalabilityScalability is a system’s ability to accommodate a growing user population, without performance degradation, by the addition of processing resources. The two general means of scaling a system are vertical and horizontal scaling. The subject of this section is the application of scaling techniques to the Portal Server product.
Benefits of scalable systems include:
Vertical Scaling
In vertical scaling, CPUs, memory, multiple instances of Portal Server, or other resources are added to one machine. This enables more process instances to run simultaneously. In Portal Server, you want to make use of this by planning and sizing to the number of CPUs you will need. See Chapter 4, "Pre-Deployment Considerations" for more information.
Horizontal Scaling
In horizontal scaling, machines are added. This also enables multiple simultaneous processing and a distributed work load. In Portal Server, you make use of horizontal scaling because you can run the Portal Server, Directory Server and Identity Server on different nodes. Horizontal scaling can also make use of vertical scaling, by adding more CPUs, for example.
Additionally, you can scale a Portal Server installation horizontally by installing server component instances on multiple machines. Each installed server component instance executes an HTTP process, which listens on a TCP/IP port whose number is determined at installation time. Gateway components use a round-robin algorithm to assign new session requests to server instances. While a session is established, an HTTP cookie, stored on the client, indicates the session server. All subsequent requests go to that server.
The section Working with Portal Server Building Modules, discusses an approach to a specific type of configuration that provides optimum performance and horizontal scalability.
Portal Server and High AvailabilityHigh Availability ensures that your portal platform is accessible 24 hours a day, seven days a week. Today, organizations require that data and applications always be available. High availability has become a requirement that applies not only to mission-critical applications, but also to the whole IT infrastructure.
System availability is affected not only by computer hardware and software, but also by people and processes, which can account for up to 80 percent of system downtime. Availability can be improved through a systematic approach to system management and by using industry best practices to minimize the impact of human error.
One important issue to consider is that not all systems have the same level of availability requirements. Most applications can be categorized into the following three groups:
- Task critical—Affects limited number of users; not visible to customers; small impact on costs and profits
- Business critical—Affects significant number of users; might be visible to some customers; significant impact on costs and profits
- Mission critical—Affects a large number of users; visible to customers; major impact on costs and profits
The goals of these levels are to improve the following:
The more mission critical the application, the more you need to focus on availability to eliminate any single point of failure (SPOF), and resolve people and processes issues.
Even if a system is always available, instances of failure recovery might not be transparent to end users. Depending on the kind of failure, users can lose the context of their portal application, and might have to login again to get access to their Portal Desktop.
System Availability
System availability is often expressed as a percentage of the system uptime. A basic equation to calculate system availability is:
Availability = uptime / (uptime + downtime) * 100
For instance, a service level agreement uptime of four digits (99.99 percent) means that in a month the system can be unavailable for about seven hours. Furthermore, system downtime is the total time the system is not available for use. This total includes not only unplanned downtime, such as hardware failures and network outages, but also planned downtime, preventive maintenance, software upgrade, and patches.
If the system is supposed to be available seven days a week, 24 hours a day, the architecture needs to include redundancy to avoid planned and unplanned downtime to ensure high availability.
Degrees of High Availability
High availability is not just a switch that you can turn on and off. There are various degrees of high availability that refer to the ability of the system to recover from failures and ways of measuring system availability. The degree of high availability depends on your specific organization’s fault tolerance requirements and ways of measuring system availability.
For example, your organization might tolerate the need to reauthenticate after a system failure, so that a request resulting in a redirection to another login screen would be considered successful. For other organizations, this might be considered a failure, even though the service is still being provided by the system.
Session failover alone is not the ultimate answer to transparent failover, because the context of a particular portal application can be lost after a failover. For example, consider the case where a user is composing a message in NetMail Lite, has attached several documents to the email, then the server fails. The user will be redirected to another server and NetMail Lite will have lost the user’s session and the draft message. Other providers, which store contextual data in the current JVM, have the same problem.
Achieving High Availability for Portal Server
Making Portal Server highly available involves ensuring high availability on each of the following components:
- Gateway—A load balancer used with the Gateway detects a failed Gateway component and routes new requests to other Gateways. A load balancer also has the ability to intelligently distribute the workload across the server pool. Routing is restored when the failed Gateway recovers. Gateway components are stateless (session information is stored on the client in an HTTP cookie) so rerouting around a failed Gateway is transparent to users.
- Portal Server—In open mode, you can use a load balancer to detect a failed server component and redirect requests to other servers. In secure mode, Gateway components can detect the presence of a failed server component and redirect requests to other servers. (This is valid as long as the web container is the Sun Java System Web Server product (formerly Sun ONE Directory Server).)
- Directory Server—A number of options make the LDAP directory highly available. See Building Modules and High Availability Scenarios for more information.
- Netlet and Rewriter Proxies—In the case of a software crash, a watchdog process automatically restarts the proxies. In addition, the Gateway performs load balancing and failure detection failover for the proxies.
Portal Server System Communication LinksFigure 5-1 shows the processes and communication links of a Portal Server system that are critical to the availability of the solution.
Figure 5-1
Portal Server Communication Links
In this figure, the box encloses the Portal Server instance running on a Sun Java System Web Server. Within the instance are five servlets (Authentication, Identity Server administration console, Portal Desktop, Communication Channel, and Search), and the three SDKs (Identity Server SSO, Identity Server Logging, and Identity Server 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 Identity Server SSO SDK and the LDAP server; and between the Identity Server Management SDK and the LDAP server.
- Figure 5-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 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 files.
Portal Server is built on top of Identity Server for authentication single sign-on (session) management, policy, and profile database access. Thus, Portal Server inherits all the benefits (and constraints) of Identity Server with respect to availability and fault tolerance.
By design, Identity Server’s services are either stateless or they can share context data so that they can recover to the previous state in case of a service failure.
Within Portal Server, Portal Desktop and NetMail services do 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 Sun Java System 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 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 those instances. Session stickiness is not required in front of a Gateway, although it is recommended for performance reasons. On the other hand, session stickiness to Portal Server instances is enforced by SRA.
Working with Portal Server Building ModulesBecause deploying Portal Server is a complex process involving many other systems, this section describes a specific configuration that provides optimum performance and horizontal scalability. This configuration is known as a Sun Java System Portal Server building module.
A Portal Server building module is a hardware and software construct with limited or no dependencies on shared services. A typical deployment uses multiple building modules to achieve optimum performance and horizontal scalability. Figure 5-2 shows the building module architecture.
Figure 5-2 Portal Server Building Module Architecture
Building Modules and High Availability Scenarios
Portal Server provides three scenarios for high availability:
The system is always available but in addition to NSPOF, failover to a backup instance occurs transparently to end users. In most cases, users do not even notice they have been redirected to a different node or instance. Sessions are preserved across nodes so that users do not have to reauthenticate. Portal Server services are stateless or use checkpointing mechanisms to rebuild the current execution context up to a certain point.
Possible supported architectures include the following:
This section explains implementing these architectures and leverages the building module concept, from a high-availability standpoint.
Table 5-1 summarizes these high availability scenarios along with their supporting techniques.
Note
Load balancing is not provided out-of-the-box with the Sun Java System Web Server web application container.
Best Effort
In this scenario, you install Portal Server and Directory Server on a single node that has a secured hardware configuration for continuous availability, such as Sun Fire UltraSPARC® III machines. (Securing a Solaris Operating Environment system requires that changes be made to its default configuration.)
This type of server features full hardware redundancy, including: redundant power supplies, fans, system controllers; dynamic reconfiguration; CPU hot-plug; online upgrades; and disks rack that can be configured in RAID 0+1 (striping plus mirroring), or RAID 5 using a volume management system, which prevents loss of data in case of a disk crash. Figure 5-3 shows a small, best effort deployment using the building module architecture.
Figure 5-3 Best Effort Scenario
In this scenario, for memory allocation, four CPUs by eight GB RAM (4x8) of memory is sufficient for one building module. The Identity Server console is outside of the building module so that it can be shared with other resources. (Your actual sizing calculations might result in a different allocation amount.)
This scenario might suffice for task critical requirements. Its major weakness is that a maintenance action necessitating a system shutdown results in service interruption.
When SRA is used, and a software crash occurs, a watchdog process automatically restarts the Gateway, Netlet Proxy, and Rewriter Proxy.
No Single Point of Failure
Portal Server natively supports the no single point of failure (NSPOF) scenario. NSPOF is built on top of the best effort scenario, and in addition, introduces replication and load balancing.
Figure 5-4 No Single Point of Failure Example
As stated earlier, a building module consists of a a Portal Server instance, a Directory Server master replica for profile reads and a search engine database. As such, at least two building modules are necessary to achieve NSPOF, thereby providing a backup if one of the building modules fails. These building modules consist of four CPUs by eight GB RAM.
When the load balancer detects Portal Server failures, it redirects users’ requests to a backup building module. Accuracy of failure detection varies among load balancing products. Some products are capable of checking the availability of a system by probing a service involving several functional areas of the server, such as the servlet engine, and the JVM. In particular, most vendor solutions from Resonate, Cisco, Alteon, and others enable you to create arbitrary scripts for server availability. As the load balancer is not part of the Portal Server software, you must acquire it separately from a third-party vendor.
Multi-master replication (MMR) takes places between the building modules. The changes that occur on each directory are replicated to the other, which means that each directory plays both roles of supplier and consumer. For more information on MMR, refer to the Directory Server 6 Deployment Guide.
Redundancy is equally important to the directory master so that profile changes through the administration console or the Portal Desktop, along with consumer replication across building modules, can always be maintained. Portal Server and Identity Server support MMR. The NSPOF scenario uses a multi-master configuration. In this configuration, two suppliers can accept updates, synchronize with each other, and update all consumers. The consumers can refer update requests to both masters.
SRA follows the same replication and load balancing pattern as Portal Server to achieve NSPOF. As such, two SRA Gateways and pair of proxies are necessary in this scenario. The SRA Gateway detects a Portal Server instance failure when the instance does not respond to a request after a certain time-out value. When this occurs, the HTTPS request is routed to a backup server. The SRA Gateway performs a periodic check for availability until the first Portal Server instance is up again.
The NSPOF high availability scenario is suitable to business critical deployments. However, some high availability limitations in this scenario might not fulfill the requirements of a mission critical deployment.
Transparent Failover
Transparent failover uses the same replication model as the NSPOF scenario but provides additional high availability features, which make the failover to a backup server transparent to end users.
Figure 5-5 shows a transparent failover scenario. Two building modules are shown, consisting of four CPUs by eight GB RAM. Load balancing is responsible for detecting Portal Server failures and redirecting users’ requests to a backup Portal Server in the building module. Building Module 1 stores sessions in the sessions repository. If there is a crash, the application server retrieves sessions created by Building Module 1 from the sessions repository.
Figure 5-5 Transparent Failover Example Scenario
The session repository is provided by the application server software. Portal Server is running in an application server. Portal Server supports transparent failover on application servers that support HttpSession failover. (Sun Java System Web Server and Sun Java System Application Server do not support HTTP Session failover.) See Appendix C, "Portal Server and Application Servers" for more information.
With session failover, users do not need to reauthenticate after a crash. In addition, portal applications can rely on session persistence to store context data used by the checkpointing. You configure session failover in the AMConfig.properties file by setting the com.iplanet.am.session.failover.enabled property to true.
The Netlet Proxy cannot support the transparent failover scenario because of the limitation of the TCP protocol. The Netlet Proxy tunnels TCP connections, and you cannot migrate an open TCP connection to another server. A Netlet Proxy crash drops off all outstanding connections that would have to be reestablished.
Building Module Constraints
The constraints on the scalability of building modules are given by the number of LDAP writes resulting from profile updates and the maximum size of the LDAP database. For more information, see Directory Server Requirements.
Note
If the LDAP server crashes with the _db files in the /tmp directory, most likely they will be gone when the server restarts. This improves performance but also affects availability.
If the analysis at your specific site indicates that the number of LDAP write operations is indeed a constraint, some of the possible solutions include creating building modules that replicate only a specific branch of the directory and a layer in front that directs incoming requests to the appropriate instance of portal.
Deploying Your Building Module Solution
This section describes guidelines for deploying your building module solution.
Deployment Guidelines
How you construct your building modue affects performance. Consider the following recommendations to deploy your building module properly:
- Deploy a building module on a single machine.
- If you use multiple machines, or if your Portal Server machine is running a large number of instances, use a fast network interconnect.
- On servers with more than eight CPUs, create processor sets or domains with either two or four CPUs. For example, if you choose to install two instances of Portal Server on an eight CPU server, create two four-CPU processor sets.
Directory Server Requirements
Identify your Directory Server requirements for your building module deployment. For specific information on Directory Server deployment, see the Directory Server Deployment Guide.
Consider the following Directory Server guidelines when you plan your Portal Server deployment:
- The amount of needed CPU in the Directory Server consumer replica processor set depends on the number of Portal Server instances in the building module as well as performance and capacity considerations.
- If possible, dedicate a Directory Server instance for the sole use of the Portal Server instances in a building module. (See Figure 5-2.)
- Map the entire directory database indexes and cache in memory to avoid disk latency issues.
- When deploying multiple building modules, use a multi-master configuration to work around bottlenecks caused by the profile updates and replication overhead to the Directory Server supplier.
Search Engine Structure
When you deploy the Search Engine as part of your building module solution, consider the following:
- In each building module, make sure only one Portal Server instance has the Search Engine database containing the RDs. The remaining Portal Server instances have default empty Search Engine databases.
- Factors that influence whether to use a building module for the portal Search database include the intensity of search activities in a Portal Server deployment, the range of search hits, and the average number of search hits for all users, in addition to the number of concurrent searches. For example, the load generated on a server by the Search Engine can be both memory and CPU intensive for a large index and heavy query load.
- You can install Search on a machine separate from Portal Server, to keep the main server dedicated to portal activity. When you do so, you use the searchURL property of the Search provider to point to the second machine where Search is installed. The Search instance is a normal portal instance. You install the Search instance just as you do the portal instance, but use it just for Search functionality.
- The size of the Search database dictates whether more than one machine needs to host the Search database by replicating it across machines or building module. Consider using high-end disk arrays.
- Use a proxy server for caching the search hit results. When doing so, you need to disable the document level security. See the Portal Server 6 Administration Guide for more information on document level security.
Designing Portal Use Case ScenariosUse case scenarios are written scenarios used to test and present the system’s capabilities, and they form an important part of your high-level design. Though you implement use case scenarios toward the end of the project, formulate them early on in the project, once you have established your requirements.
When available, use cases can provide valuable insight into how the system is to be tested. Use cases are beneficial in identifying how you need to design the user interface from a navigational perspective. When designing use cases, compare them to your requirements to get a thorough view of their completeness and how you are to interpret the test results.
Use cases provide a method for organizing your requirements. Instead of a bulleted list of requirements, you organize them in a way that tells a story of how someone can use the system. This provides for greater completeness and consistency, and also gives you a better understanding of the importance of a requirement from a user perspective.
Use cases help to identify and clarify the functional requirements of the portal. Use cases capture all the different ways a portal would be used, including the set of interactions between the user and the portal as well as the services, tasks, and functions the portal is required to perform.
A use case defines a goal-oriented set of interactions between external actors and the portal system. (Actors are parties outside the system that interact with the system, and can be a class of users, roles users can play, or other systems.)
Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain.
Use case scenarios are an instance of a use case, representing a single path through the use case. Thus, there may be a scenario for the main flow through the use case and other scenarios for each possible variation of flow through the use case (for example, representing each option).
Elements of Portal Use Cases
When developing use cases for your portal, keep the following elements in mind:
- Priority—Describes the priority, or ranking of the use case. For example, this could range from High to Medium to Low.
- Context of use—Describes the setting or environment in which the use case occurs.
- Scope—Describes the conditions and limits of the use case.
- Primary user—Describes what kind of user this applies to, for example, an end user or an administrator.
- Special requirements—Describes any other conditions that apply.
- Stakeholders—Describes those who have a "vested interest" in how a product decision is made or carried out.
- Precondition—Describes the prerequisites that must be met for the use case to occur.
- Minimal guarantees—Describes the minimum that must occur if the use case is not successfully completed.
- Success guarantees—Describes what happens if the use case is successfully completed.
- Trigger—Describes the particular item in the system that causes the event to occur.
- Description—Provides a step-by-step account of the use case, from start to finish.
Example Use Case: Authenticate Portal User
Table 5-2 describes a use case for a portal user to authenticate with the portal.
Designing Portal Security StrategiesSecurity is the set of hardware, software, practices, and technologies that protect a server and its users from malicious outsiders. In that regard, security protects against unexpected behavior.
You need to address security globally and include people and processes as well as products and technologies. Unfortunately, too many organizations rely solely on firewall technology as their only security strategy. These organizations do not realize that many attacks come from employees, not outsiders. Therefore, you need to consider additional tools and processes when creating a secure portal environment.
Operating Portal Server in a secure environment involves making certain changes to the Solaris Operating Environment, the Gateway and server configuration, the installation of firewalls, and user authentication through Directory Server and SSO through Identity Server. In addition, you can use certificates, SSL encryption, and group and domain access.
Securing the Operating Environment
Reduce potential risk of security breaches in the operating environment by performing the following, often termed “system hardening:”
- Minimize the size of the operating environment installation—When installing a Sun server in an environment that is exposed to the Internet, or any untrusted network, reduce the Solaris installation to the minimum number of packages necessary to support the applications to be hosted. Achieving minimization in services, libraries, and applications helps increase security by reducing the number of subsystems that must be maintained.
- Track and monitor file system changes—Within systems that require inclusion of security, a file change control and audit tool is indispensable as it tracks changes in files and detects possible intrusion. You can use a product such as Tripwire for Servers, or Solaris Fingerprint Database (available from SunSolve Online).
Using Platform Security
Usually you install Portal Servers in a trusted network. However, even in this secure environment, security of these servers requires special attention.
UNIX User Installation
You can install and configure Portal Server to run under three different UNIX users:
- root—This is the default option. All Portal Server components are installed and configured to run as the system superuser. Some security implications arise from this configuration:
- User nobody—You can install Portal Server as the user nobody (uid 60001). This can improve the security of the system, because the user nobody does not have any privileges and cannot create, read, or modify the system files. This feature prevents user nobody from using Portal Server to gain access to system files and break into the system.
The user nobody does not have a password, which prevents a regular user from becoming nobody. Only the superuser can change users without being prompted for a password. Thus, you still need root access to start and stop Portal Server services.
See the Java Enterprise System Installation Guide for more information.
- Non-root user—You can run Portal Server as a regular UNIX user. The security benefits of a regular user are similar to those provided by the user nobody. A regular UNIX user has additional benefits as this type of user can start, stop, and configure services. After installation, you need to change ownership of some files.
Limiting Access Control
While the traditional security UNIX model is typically viewed as all-or-nothing, there are alternative tools that you can use, which provide some additional flexibility. These tools provide the mechanisms needed to create a fine grain access control to individual resources, such as different UNIX commands. For example, this toolset enables Portal Server to be run as root, while allowing certain users and roles superuser privileges to start, stop, and maintain the Portal Server framework.
These tools include:
- Role-Based Access Control (RBAC)—Solaris 8 and 9 include the Role-Based Access Control (RBAC) to package superuser privileges and assign them to user accounts. RBAC enables separation of powers, controlled delegation of privileged operations to users, and a variable degree of access control.
- Sudo—Sudo is publicly available software, which enables a system administrator to give certain users the ability to execute a command as another user. Please see:
Using a Demilitarized Zone (DMZ)
For maximum security, the Gateway is installed in the DMZ between two firewalls. The outermost firewall enables only SSL traffic from the Internet to the Gateways, which then direct traffic to servers on the internal network.
Portal Server and Identity Server on Different NodesPortal Server and Identity Server 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.
- Identity Server can be used by other web containers to assist with development of portal customizations.
The Identity Server 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 Identity Server 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.
Figure 5-6 illustrates Identity Server and Portal Server residing on separate nodes.
Figure 5-6 Portal Server and Identity Server on Different Nodes
As a result of this implementation of Portal Server and Identity Server separation, there are other possible topology permutations for portal services architecture deployments as shown in the next three figures.
Figure 5-7 shows two Portal Server instances configured to work with a single Identity Server and two Directory Servers where both the Identity Server and the Directory Servers operate in a Java Enterprise System Sun Clustered environment. This configuration is ideal when it is determined that the Identity and Directory Server instances are not the bottleneck.
Figure 5-7 Two Portal Server
s and One Identity Server
Figure 5-8 shows configuration allowing authentication throughput coming from Portal Server to be load-balanced across the two Identity Servers.
This configuration could be implemented when the Portal Server resides on a high-end medium to large server (that is 1 to 4 processors) with a very wide bandwidth network connection. The Identity Servers with the policy and authentication services could be on two medium-size servers.
Figure 5-8 One Portal Server and Two Identity Servers
Figure 5-9 shows a configuration for maximum horizontal scalability and higher availability achieved by a horizontal server farm. Two Portals Servers can be fronted with a load balancer for maximum throughput and high availability.
Another load balancer can be put between Portal Servers and Identity Servers to achieve authentication and policy processes as a load distributor and failover mechanism for higher availability.
In this scenario, Blade 1500s can be utilized for Portal Services to distribute the load, similar Blades can be used to host Identity Services and Directory Services respectively. With the architecture shown in Figure 5-9 there is redundancy of services for each of the product stack, therefore, most of the unplanned downtime can be minimized or eliminated.
However, the planned downtime is still an issue. If an upgrade or patch includes changes to the Sun Java Enterprise Directory Server software schema used by the Sun Java Enterprise Identity Server software, all of the software components must be stopped to update the schema information stored in the Directory Server. However, updating schema information can be considered a fairly rare occurence in most patch upgrades.
Figure 5-9 Two Portal Servers and Two Identity
Servers
Designing SRA Deployment ScenariosThe SRA Gateway provides the interface and security barrier between the remote user sessions originating from the Internet and your organization’s intranet. The Gateway serves two main functions:
For Internet access, use 128-bit SSL to provide the best security arrangement and encryption or communication between the user’s browser and Portal Server. The Gateway, Netlet, NetFile, Netlet Proxy, Rewriter Proxy, and Proxylet constitute the major components of SRA.
This section lists some of the possible configurations of these components. Choose the right configuration based on your business needs. This section is meant only as a guide. It is not meant to be a complete deployment reference.
Basic SRA Configuration
Figure 5-10 shows the most simple configuration possible for SRA. The figure shows a client browser running NetFile and Netlet. The Gateway is installed on a separate machine in the DMZ between two firewalls. The Portal Server is located on a machine beyond the second firewall in the intranet. The other application hosts that the client accesses are also located beyond the second firewall in the intranet.
The Gateway is in the DMZ with the external port open in the firewall through which the client browser communicates with the Gateway. In the second firewall, for HTTP or HTTPS traffic, the Gateway can communicate directly with internal hosts. If security policies do not permit it, use SRA proxies between the Gateway and the internal hosts. For Netlet traffic, the connection is direct from the Gateway to the destination host.
Without a SRA proxy, the SSL traffic is limited to the Gateway and the traffic is unencrypted from the Gateway to the internal host (unless the internal host is running in HTTPS mode). Any internal host to which the Gateway has to initiate a Netlet connection should be directly accessible from DMZ. This can be a potential security problem and hence this configuration is recommended only for the simplest of installations.
Figure 5-10 Basic SRA Configuration
Disable Netlet
Figure 5-11 shows a scenario similar to the basic SRA configuration except that Netlet is disabled. If the client deployment is not going to use Netlet for securely running applications that need to communicate with intranet, then use this setup for performance improvement.
You can extend this configuration and combine it with other deployment scenarios to provide better performance and a scalable solution.
Figure 5-11 Disable Netlet
Proxylet
Figure 5-12 Proxylet enables users to securely access intranet resources through the Internet without exposing these resources to the client.
It inherits the transport mode (either HTTP or HTTPS) from the Gateway.
Figure 5-12 Proxylet
Multiple Gateway Instances
Figure 5-13 shows an extension of the SRA basic configuration. Multiple Gateway instances run on the same machine or multiple machines. You can start multiple Gateway instances with different profiles. See Chapter 2, “Configuring the Gateway,” in the Portal Server Secure Remote Access 6 Administration Guide for details.
Figure 5-13 Multiple Gateway Instances
Note
Although Figure 5-13 shows a 1-to-1 correspondence between the Gateway and the Portal Servers, this need not necessarily be the case in a real deployment. You can have multiple Gateway instances, and multiple Portal Server instances, and any Gateway can contact any Portal Server depending on the configuration.
The disadvantage to this configuration is that multiple ports need to be opened in the second firewall for each connection request. This could cause potential security problems.
Netlet and Rewriter Proxies
Figure 5-14 shows a configuration with a Netlet Proxy and a Rewriter Proxy on the intranet. With these proxies, only two open ports are necessary in the second firewall.
The Gateway need not contact the application hosts directly now, but will forward all Netlet traffic to the Netlet proxy and Rewriter traffic to the Rewriter Proxy. Since the Netlet Proxy is within the intranet, it can directly contact all the required application hosts without opening multiple ports in the second firewall.
The traffic between the Gateway in the DMZ and the Netlet Proxy is encrypted, and gets decrypted only at the Netlet Proxy, thereby enhancing security.
If the Rewriter Proxy is enabled, all traffic is directed through the Rewriter Proxy, irrespective of whether the request is for the Portal Server node or not. This ensures that the traffic from the Gateway in the DMZ to the intranet is always encrypted.
Because the Netlet Proxy, Rewriter Proxy, and Portal Server are all running on the same node, there might be performance issues in such a deployment scenario. This problem is overcome when proxies are installed on a separate nodes to reduce the load on the Portal Server node.
Figure 5-14 Netlet and Rewriter Proxies
Netlet and Rewriter Proxies on Separate Nodes
To reduce the load on the Portal Server node and still provide the same level of security at increased performance, you can install Netlet and Rewriter Proxies on separate nodes. This deployment has an added advantage in that you can use a proxy and shield the Portal Server from the DMZ. The node that runs these proxies needs to be directly accessible from the DMZ.
Figure 5-15 shows the Netlet Proxy and Rewriter Proxy on separate nodes. Traffic from the Gateway is directed to the separate node, which in turn directs the traffic through the proxies and to the required intranet hosts.
You can have multiple instances or installations of Netlet and Rewriter Proxies. You can configure each Gateway to try to contact various instances of the proxies in a round robin manner depending on availability.
Figure 5-15 Proxies on Separate Nodes
Using Two Gateways and Netlet Proxy
Figure 5-16 Load balancers provide a failover mechanism for higher availability as there is a redundancy of services on the Portal Servers and Identity Servers. Two Gateways and Netlet Proxy
Using an Accelerator
You can configure an external SSL device to run in front of the Gateway in open mode. It provides the SSL link between the client and SRA. For information on accelerators, see the Portal Server Secure Remote Access 6 Administration Guide.
Figure 5-17 SRA Gateway with External Accelerator
Netlet with 3rd Party Proxy
Figure 5-18 illustrates using a third-party proxy to limit the number of ports in the second firewall to one. You can configure the Gateway to use a third-party proxy to reach the Rewriter and the Netlet Proxies.
Figure 5-18
Netlet and Third-Party Proxy
Reverse Proxy
A proxy server serves Internet content to the intranet, while a reverse proxy serves intranet content to the Internet. Certain deployments of reverse proxy are configured to serve the Internet content to achieve load balancing and caching.
Figure 5-19 illustrates how you can configure a reverse proxy in front of the Gateway to serve both Internet and intranet content to authorized users. Whenever the Gateway serves web content, it needs to ensure that all subsequent browser requests based on this content are routed through the Gateway. This is achieved by identifying all URLs in this content and rewriting as appropriate.
Figure 5-19 Using a Reverse Proxy in Front of the Gateway
Designing for LocalizationLocalization is the process of adapting text and cultural content to a specific audience. Localization can be approached in two different ways:
For advanced language localization, create a well-defined directory structure for template directories.
To preserve the upgrade path, maintain custom content and code outside of default directories. See the Portal Server 6 Developer’s Guide for more information on localization.
Content and Design ImplementationThe Portal Desktop provides the primary end-user interface for Portal Server and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI). The Portal Desktop includes a variety of providers that enable container hierarchy and the basic building blocks for building some types of channels. For storing content provider and channel data, the Portal Desktop implements a display profile data storage mechanism on top of an Identity Server service.
The various techniques you can use for content aggregation include:
See the Portal Server 6 Developer’s Guide and Portal Server 6 Desktop Customization Guide for more information.
Placement of Static Portal Content
Place your static portal content in the web-container-install-root/SUNWam/public_html directory or in a subdirectory under the web-container-install-root/SUNWam/public_html directory (the document root for the web container). Do not place your content in the web-container-install-root/SUNWps/web-apps/https-server/portal/ directory, as this is a private directory. Any content here is subject to deletion when the Portal Server web application is redeployed during a patch or other update.
Integration Design
This section provides information on integration areas that you need to account for in your low-level design.
Creating a Custom Identity Server Service
Service Management in Identity Server provides a mechanism for you to define, integrate, and manage groups of attributes as an Identity Server service. Readying a service for management involves:
- Creating an XML service file
- Configuring an LDIF file with any new object classes and importing both the XML service file and the new LDIF schema into Directory Service
- Registering multiple services to organizations or sub-organizations using the Identity Server administration console
- Managing and customizing the attributes (once registered) on a per organization basis
See the Identity Server documentation for more information.
Integrating Applications
Integrating and deploying applications with Portal Server is one of your most important deployment tasks. The application types include:
- Channel—Provides limited content options; is not a “mini-browser”.
- Portlet—Pluggable web component that processes requests and generates content within the context of a portal. In Portal Server software, a portlet is managed by the Portlet Container. Conceptually, a portlet is equivalent to a Provider.
- Portal application—Launched from a channel in its own browser window; the Portal Server hosts the application; an example is NetMail; created as an Identity Server service; accesses Portal and Identity Server APIs.
- Third-party application—Hosted separately from Portal Server, but accessed from Portal Server; URL Scraper, which calls Rewriter, rewrites web pages so that they can be displayed in a channel; uses Identity Server to enable single sign-on.
Independent Software Vendors
Listed below are some types of independent software vendor (ISV) integrations.
- Application user interface—This integration uses the provider API and SRA for secure access. (SRA is not an integration type on its own.) Examples include FatWire, Interwoven, SAP, Tarantella, Documentum, Vignette, PeopleSoft, Siebel, Citrix, and YellowBrix.
- Security products—This integration uses the Identity Server Login API to enable portal access by using a custom authentication scheme. Examples include RSA.
- Content Management—This integration provides data access into Portal Server, enabling searches on the data. Examples include FatWire, Interwoven, and Vignette.
- Content Syndication—This integration provides managing and customizing information that appears on websites. Examples include YellowBrix and Pinnacor.
- Collaboration software—This integration enables Sun Java System Instant Messaging product to move a collaboration session from one forum to a another. Examples include WebEx, BeNotified, and Lotus.
- Monitoring—This integration focuses on billing, performance measurement, and diagnostics, for which you rely on log files (or Identity Server’s Logging API) and traffic snooping. Examples include Mercury Interactive, Hyperion, and Informatica.
- Portal capability augmentation—This integration enables products to add functionality to Portal Server. Examples include Altio, Bowstreet, rule engines to add group capability, and dynamic standard Portal Desktop and provider contents (HNC).
- Integratable portal stack—This integration includes products that replace elements of Portal Server. Examples include Identity Server and LDAP.
The “depth” to which user interface integration occurs with Portal Server indicates how complete the integration is. Depth is a term used to describe the complementary nature of the integration, and points to such items as:
In general, the degree to which an application integrates in Portal Server can be viewed as follows:
- Shallow integration—This integration essentially uses the Portal Server as a launch point. The user logs in to the portal and clicks a link that starts a web application.
- Deep integration—The user accesses the user interface provided by the channels in Portal Server directly. That is, the integrated software works within the portal. No additional windows or applets appear.
Integrating Microsoft Exchange
Using the JavaMail API is one of the primary options for integrating Microsoft Exchange messaging server with Portal Server. The JavaMail API provides a platform independent and protocol independent framework to build Java technology-based mail and messaging applications. The JavaMail API is implemented as a Java platform optional package and is also available as part of the Java 2 Platform, Enterprise Edition.
JavaMail provides a common uniform API for managing mail. It enables service providers to provide a standard interface to their standards based or proprietary messaging systems using Java programming language. Using this API, applications can access message stores and compose and send messages.
Identity and Directory Structure DesignA major part of implementing your portal involves designing your directory information tree (DIT), which organizes your users, organizations, suborganizations into a logical or hierarchical structure that enables you to efficiently administer and assign appropriate access to the users assuming those roles or contained within those organizations.
The top of the organization tree in Identity Server is called dc=fully-qualified-domain-name by default, but can be changed or specified at install time. Additional organizations can be created after installation to manage separate enterprises. All created organizations fall beneath the top-level organization. Within these suborganizations other suborganizations can be nested. There is no limitation on the depth to the nested structure.
Roles are a grouping mechanism designed to be more efficient and easier to use for applications. Each role has members, or entries that possess the role. As with groups, you can specify role members either explicitly or dynamically.
The roles mechanism automatically generates the nsRole attribute containing the distinguished name (DN) of all role definitions in which the entry is a member. Each role contains a privilege or set of privileges that can be granted to a user or users. Multiple roles can be assigned to a single user.
The privileges for a role are defined in Access Control Instructions (ACIs). Portal Server includes several predefined roles. The Identity Server administration console enables you to edit a role’s ACI to assign access privileges within the Directory Information Tree. Built-in examples include SuperAdmin Role and TopLevelHelpDeskAdmin roles. You can create other roles that can be shared across organizations.
See the Portal Server 6 Administration Guide, Directory Server Deployment Guide, and the Identity Server Deployment Guide for more information on planning your Identity Server and Directory Server structure.
Implementing Single Sign-On
Single sign-on (SSO) to Portal Server is managed by Identity Server. SSO provides a user with the ability to use any application that has its access policy managed by Identity Server, if allowed through the policy. The user need not re-authenticate to that application.
Various SSO scenarios include:
- Portal web application—The authentication comes from Identity Server, and the application validates the user credentials with Identity Server
- Standalone web application—The application is hosted on a separate web container, and the Identity Server Web Agent is used for authentication. This does not require application coding. Additionally, you can modify the application to validate against Identity Server directly.
- Standalone Java application—In this scenario, you modify the application to validate user credentials against Identity Server directly.
- Non-Identity Server aware application—In this scenario an application stores a user’s credentials and provides them as needed. However, this is not an ideal SSO solution, as the user needs to re-authenticate if credentials change.
Portal Desktop Design
The performance of Portal Server itself largely depends upon how fast individual channels perform. In addition, the user experience of the portal is based upon the speed with which the Portal Desktop is displayed. The Portal Desktop can only load as fast as the slowest displayed channel. For example, consider a Portal Desktop composed of ten channels. If nine channels are rendered in one millisecond but the tenth takes three seconds, the Portal Desktop does not appear until that tenth channel is processed by the portal. By making sure that each channel can process a request in the shortest possible time, you provide a better performing Portal Desktop.
Choosing and Implementing the Correct Aggregration Strategy
The options for implementing portal channels for speed and scalability include:
- Keeping processing functions on back-end systems and application servers, not on the portal server. The portal server needs to optimize getting requests from the user. Push as much business logic processing to the back-end systems. Whenever possible, use the portal to deliver customized content to the users, not to process it.
- Ensuring that the back-end systems are highly scalable and performing. The Portal Desktop only responds as fast as the servers from which it obtains information (to be displayed in the channels).
- Understanding where data is stored when designing providers, how the portal gets that data, how the provider gets that data, and what kind of data it is. For example, is the data dynamic that pertains to an individual user, or is there code needed to retrieve that customized or personalized data? Or, is the data static and shared by a small group of users? Next, you need to understand where the data resides (for example, in an XML file, database and flat file), and how frequently it is updated. Finally, you need to understand how the business logic is applied for processing the data, so that the provider can deliver a personalized channel to the user.
Working with Providers
Consider the following when planning to deploy providers:
- URLScraperProvider—Typically you use this provider to access dynamic content that is supplied by another web container’s web-based system. It uses HTTP and HTTPS calls to retrieve the content. This provider puts high requirements on the back-end system, as the back-end system has to be highly scalable and available. Performance needs to be in double-digit milliseconds or hundredths of milliseconds to show high performance. This provider is very useful for proof of concept in the trial phase of your portal deployment due to the simplicity of configuration.
URLScraperProvider also performs some level of rewriting every time it retrieves a page. For example, if a channel retrieves a news page that contains a picture that is hosted on another web site, for the portal to be able to display that picture, the URL of that picture needs to be rewritten. The portal does not host that picture, so URLScraperProvider needs to rewrite that picture to present it to portal users.
The URL Scraper provider that is part of Portal Server can also function as a file scraper provider.
To use URLScraperProvider as a file scraper provider, specify the URL as follows:
String name="url" value="file://path/filename"
This is the best performing provider, in terms of how fast it is able to retrieve content. On the first fetch of content, performance for this provider is usually in the low teen milliseconds. On subsequent requests, using a built-in caching mechanism, this provider can usually deliver content in one millisecond or less. If applicable, consider using the file scraper provider in place of the URL Scraper provider.
- JSPProvider—Uses JavaServer Pages (JSP) technology. JSPProvider obtains content from one or more JSP files. A JSP file can be a static document (HTML only) or a standard JSP file with HTML and Java code. A JSP file can include other JSP files. However, only the topmost JSP file can be configured through the display profile. The topmost JSP files are defined through the contentPage, editPage, and processPage properties.
- LoginProvider—Provides access to the Identity Server authentication service through a Portal Desktop channel. This provider enables anonymous Portal Desktop login so that a user can log in directly from the Portal Desktop.
- XMLProvider—Transforms an XML document into HTML using an XSLT (XML Style Sheet Language) file. You must create the appropriate XSLT file to match the XML document type. XMLProvider is an extension of URLScraperProvider. This provider uses the JAXP 1.2 JAR files provided by Sun Java System Web Server software.
- LDAP-based provider—This type of provider retrieves information about a user and use of personalization from user profile. It stays efficient as long as the number of LDAP attributes stored is low. In general, this type of provider is a good performer, second only to the file scraper provider within URLScraperProvider.
- Database provider—This type of provider utilizes a back-end database for its content. It requires that you build database connection polling and that you use small queries (either single queries, or no more than a couple). You might also have to perform extra work for HTML formatting. In general, this type of provider is the worst performer, due to its use of database connection pooling, large database queries, poor coding, or lack of indexing on the retrieved data. Additionally, once the data has been retrieved, the portal needs to perform a large amount of processing to display the data in the Portal Desktop. If you use this type of provider, push as much data processing logic to the database as possible. Also, benchmark your portal performance with and without database channels in the user profile.
Client Support
Portal Server supports the following browsers as clients:
See the Portal Server 6 Release Notes for updates to this list.
Multiple client types, whether based on HTML, WML, or other protocols, can access Identity Server and hence Portal Server. For this functionality to work, Identity Server uses the Client Detection service (client detection API) to detect the client type that is accessing the portal. The client type is then used to select the portal template and JSP files and the character encoding that is used for output.
Sun Java System Portal Server Mobile Access 6.3 software extends the services and capabilities of the Portal Server platform to mobile devices and provides a framework for voice access. The software enables portal site users to obtain the same content that they access using HTML browsers.
Mobile Access software supports mobile markup languages, including xHTML, cHTML, HDML, HTML, and WML. It can support any mobile device that is connected to a wireless network through a LAN or WAN using either the HTTP or HTTPS protocol. In fact, the Portal Server Mobile Access software could support any number of devices, including automobiles, set-top boxes, PDAs, cellular phones, and voice.