Portal Server enables enterprises to design a variety of deployment scenarios. This section provides the following topics:
Each enterprise assesses its own needs and plans its own deployment of Java Enterprise System. The optimal deployment for each enterprise depends on a variety of factors, including:
The types of applications that Java ES is supporting
The number of users
What hardware is available
For more information about deployment planning and deployment scenarios, see the Sun Java System Portal Server 7 Deployment Planning Guide.
You can run Portal Server in open mode or secure mode, with or without Sun Java System Portal Server Secure Remote Access server.
In open mode, Portal Server is installed without the Secure Remote Access server. The typical public portal runs without secure access using HTTP or HTTPS.
In secure mode, Portal Server is installed with the Secure Remote Access server. Secure mode provides end users with secure remote access to required intranet file systems and applications. Only the IP address of the Gateway is published to the Internet.
Portal Server supports multiple portals using a single user repository. You can design, deploy, and administer each portal independently. Setting up multiple portals allows administrators to do the following:
Deploy multiple portals and portal server instances on one or more hosts
Use Access Manager software to manage users for all portals
Provide different content for different portals
Offer single sign-on (SSO) between portals
Enable users to customize their desktops for each portal
To manage users, portal administrators use tools provided by Access Manager. User data in LDAP directories does not need to be synchronized with any other repository.
A portal is a collection of one or more Portal Server instances that deliver the same content and are mapped to a single URL. The content and services delivered by a portal are common to all of its instances.
A Portal Server instance is a web application deployed into a web container, using a particular portal context URI and serving requests on a specific network port. Each Portal Server instance is associated with a single portal.
Multiple portals share the same user repository, or Access Manager. These portals can be deployed on one or more hosts. Portals that use different Access Managers are not multiple portals.
Single sign-on (SSO) enables end users to enter a password once to gain authenticated access to various resource servers, which supply applications or services. The resource servers that an end user can access depend on what implementations of the SSO Adapter interface are available in the system.
Standard application programming interfaces (APIs) are used to provide user access to a resource server. To access a mail server, for example, an application uses the JavaMailTM API.
To create an authenticated connection using an API, administrators provide the API with the configuration data for the connection. The SSO Adapter, which uses standard database terminology, provides this configuration data for an authenticated connection, and the SSO Adapter service stores that data.
The SSO Adapter service defines two levels of data:
SSO Adapter template defines a class of connections to be made available to users. Many end users use a single template. The template defines data values that are the same for all users, including default values and what values a user can edit. Therefore, SSO Adapter templates are defined at a global service level.
SSO Adapter configuration provides data values that are specific to an organization, role, or user. A configuration references a template and takes data values from the template for properties that the end user cannot change. Whenever an end user changes the user-editable properties of an SSO Adapter configuration, that configuration change applies only to that one end user.