WebSphere Portal is all about the integration of users and administration, a common look and feel, and a standardized application programming model. With Portal, various back-end systems can be integrated to a common user experience. However, there are various cases where you will have several independent user populations and will want to provide a unique and distinguished look and feel to each of them. Each community will want to work with its own logical partition of WebSxphere Portal independent of all others.
Examining Some Typical Usage ScenariosBefore you start to set up a portal server with logical partitions for different communities, it is important to be clear about your specific needs and priorities. This section details three typical usage scenarios and their typical requirements.
Multiportal Enterprise
In the first scenario, a single enterprise owns and operates multiple and different logical portals on a single installation. For instance, there will be independent portal instances for different organizational units or brands. Usually there will be a strong emphasis on the sharing of applications, centralized administration, and a common user repository.
Workgroup Service Provider
The second scenario is very similar to the previous one, but there are significantly higher numbers of such portal instances. There can be dedicated portal services for individual teams, departments, or projects. Easy creation of additional portal instances as well as self-administration is essential to achieving a reasonable total cost of ownership (TCO). Prerequisites for this scenario are minimal memory footprint per portal instance and good scalability.
Hosted Enterprises
In this scenario a service provider hosts and operates independent enterprises on the same portal installation. A specific portal instance can be provided for each tenant. A major focus will be on self-administration by the tenant. Secure isolation between portal instances is essential. Each instance typically has its own user repository. Applications as well as data must be shielded properly between tenants. Quality of service (QoS), reliability, availability, and failure protection will be other strong requirements.
The following questions and considerations will point out that some of the key requirements in the described scenarios are orthogonal to each other.
- Is it most important that the portlets and applications of different logical portals are shielded from each other? Do you need a strong isolation of your applications? This can be achieved by having a separate Java Virtual Machine (JVM) for each portal instance. Nevertheless, the downside of this is the significant memory footprint of running multiple JVMs in parallel.
- Do you want to share data? Or is it mandatory to have a very strict isolation of your data and portal configuration? Based on this decision, either a separate or a common portal database may be required.
- Are you considering a few or hundreds of portal instances on a single installation? The answer will determine if you need to stick to a single JVM in order to minimize memory consumption.
There are two alternatives to implementing multiple portal server instances on a single hardware instance (see Figure 1). Based on the previous scenarios and questions, you need to decide which of these two options fits best for your situation.
- True portals are full parallel portal and application server installations on the same hardware instance. Each of the portal servers will run its own JVM and have its own portal configuration database. The benefit of this option is the best possible isolation of applications and data. The downside is that it is not possible to share applications between true portals. Using multiple JVMs will also have an impact on memory consumption and limit the number of true portals that can reside on the same hardware.
- Virtual portals are logical partitions within a single portal and application installation. Many such partitions are possible since this approach is highly scalable. Sharing of applications and data is possible. Concepts for isolation between virtual portals are introduced. Nevertheless, failure protection between applications is limited, due to a common JVM, which is shared among all virtual portals.
Virtual portals have been introduced as a new feature in WebSphere Portal 5.1. The following sections will explain the concepts of virtual portals in more detail.
New in WebSphere Portal 5.1: Virtual PortalsVirtual portals can be created easily within a single Websphere Portal 5.1 installation whenever you need additional logical portal instances. You do not need to repeat the portal or application server installation over and over again. Instead, you will reuse the existing Portal server on your system and avoid redundant memory footprints.
Virtual portals are based on the following key concepts:
- Can be customized to expose their unique look and feel
- Are accessed through friendly URL mappings
- The notion of scoped and nonscoped portal resources is introduced
- Each virtual portal can have its own distinct user population
- For administration of virtual portals, the delegation model of Portal Access Control is leveraged
- A new administration portlet will expose a user interface to manage virtual portals
Individual Look and FeelVirtual portals are peers of each other. Each virtual portal has its own navigation with its own context root (represented by a label), its own instances of administration portlets, and its own set of pages (see Figure 2). These pages include a login page, favorites, My Portal and the anonymous pages. You can assign a particular theme to the pages of a virtual portal in order to expose a unique look and feel to the users.
In Portal 5.1, it is now possible to use Login and Enrollment/ Self-care Portlets instead of the screens that have been used in the previous releases. These Portlets and their pages can be customized for each virtual portal.
Accessing a Virtual PortalA user can access a virtual portal using a URL mapping, which is defined during the creation of a virtual portal. The mapping points to the root page of the virtual portal that the user wants to access. Such a friendly URL for a virtual portal can look like this: www.ibm.com:9081/wps/portal/aVirtualPortal.
Internally, the URL mapping will be translated into a representation, which uses the object identifier of the virtual portal as a parameter in the URL. For instance, such an internal URL can look like this (18_0_35 is the virtual portal's object ID): www.ibm.com:9081/wps/portal/!ut/p/vp/18_0_35.
Based on the used URL, the Portal will determine which virtual portal a user wants to access. The requested virtual portal will be selected as the current context. All of the user's activities will be executed within in the context of that virtual portal.
Scoping and SharingThe requirement of isolating the content of individual virtual portals, but still allowing the sharing of applications, has been addressed in Portal 5.1 by a new concept: depending on the type of portal resource, the resource will be either be scoped to a particular virtual portal, or shared among all virtual portals of an installation.
Scoped Resources
Scoped resources belong to exactly one virtual portal. They are associated with the virtual portal in which they have been created. To use such a scoped resource, you must access the associated virtual portal. These resources are not visible or accessible from any other virtual portal and, therefore, cannot be shared among virtual portals.
Pages, portlet entities, and search indexes are scoped resource types. The scoping of these resource types is enforced by the portal. You cannot modify or override this behavior, e.g., using access control.
Shared Resources
Shared resources are available in the entire portal installation and can therefore be used by all virtual portals. Portlet definitions, portlet applications, Web modules, URL mappings, themes, and skins are shared resource types. Nevertheless, it is possible to apply portal access control and limit the usage of these shared resources to certain virtual portals. This is done by granting permissions to a shared resource only to the users of the virtual portal of choice.
Unique Names
Unique names can be either scoped or shared, depending on the resource to which they are assigned:
- Unique names of scoped resources are scoped
- Unique names of shared resources are shared
This implies that only the unique names of shared resources must be unique within the portal installation. When used for a scoped resource, the same unique names can be reused in multiple virtual portals.
Portlet Definitions and Portlet Entities
When you try to share portlets across virtual portals, one important impact of scoping and sharing surfaces: since portlet applications are shared resources, their properties will be common across the entire installation. This means that the configuration preferences of the portlet definition will have the same values for all virtual portals. If you need to define different configuration preferences for your virtual portals, you will have to clone the portlet application. Each virtual portal can use its own clone with its own individual configuration preferences.
On the other hand, the portlet entity is scoped. Any preference of portlet entities, which you have defined, will be specific to a single virtual portal. Obviously, those properties cannot be shared across virtual portals.
Installation-Wide Settings
All portal property files apply to the entire installation. You cannot define a specific setting for individual virtual portals. The same is true for portlet services and the credential vault. In the credential vault, any public credential will be visible to all virtual portals.
Defining a User Population for a Specific Virtual PortalIn Portal 5.1, you can configure WebSphere Member Manager (WMM) as a custom user registry. WMM introduces the notion of a realm. A realm aggregates a set of users within a user repository, for instance, by selecting several nodes in an LDAP tree. Realms are an abstraction of physical user registry systems; they expose a distributed user population as a single coherent entity. It is important to emphasize that realms are defined within the WMM configuration and are not part of the user registry itself. This distinguishes realms from groups.
Realms can be applied to scope users to specific virtual portals; you can associate a virtual portal with a specific realm. The realm membership is validated during authentication in order to ensure that a virtual portal can only be accessed by members of the corresponding realm. Therefore, the realm membership can be used to have a strictly separated user population for different virtual portals. Even a wpsadmin will not be able to login into a virtual portal if he/she is not a member of the corresponding realm. This security check cannot be overwritten. Nevertheless, it is possible that multiple virtual portals share the same user population by specifying the same realm relationship. Realms can overlap, which allows a user to be a member of more than one realm.
Access ControlWhen setting up a virtual portal installation, you will have two different kinds of administrators:
- The master administrator
- The VP-specific subadministrator
The master administrator is responsible for the entire installation. He/she will have administration privileges for the portal. He/she will be able to create virtual portals and will typically manage the shared resources. The master administrator will also be responsible for the installation of portlets, themes, skins, etc.
During the creation of a new virtual portal, the master administrator will delegate the administration of the new virtual portal to a group of subadministrators. The subadministrators will manage the pages, portlet entities, and users within their virtual portal (see Figure 3). The flexibility of portal access control supports the concept of virtual portals very well. By inheritance, subadministrators implicitly have the administrative access rights for all the child pages underneath the context root label of their virtual portal. Access to shared resources can be granted explicitly.
The master administrator determines the delegation of access control roles to the subadministrator. By default, only the admin role to the VP's context root label and the editor role for the VP's portlet entities will be assigned automatically. Additional roles need to be set up by the master administrator. Typically, these additional role definitions will include editor and security administrator permissions for the users and groups of this virtual portal.
Some portlets, such as Web Clipping or Search, require additional role definitions for the virtual portal's subadministrator as well.
Since all virtual portals run in the same JVM, it is unlikely that subadministrators will be allowed to deploy their own code into their virtual portal, since there is a potential risk that uncertified, poorly written, or malicious code would impact the overall stability of the installation. If individual virtual portals need to integrate their private portlets, the preferred solution would be to aggregate remote portlet services using WSRP.
Regardless of role definitions in access control, it is never possible to access or manage a scoped resource in another virtual portal, nor is it possible to administer users if you are not a member of the user's realm. These principles are enforced by the portal.
Managing Virtual PortalsThe "manage virtual portal" administration portlet provides the capabilities to manage virtual portals (see Figure 4). In order to create a virtual portal, a set of properties such as title, realm, default theme, and the designated group of subadministrators need to be specified. During the creation process, an XML Access script will be executed and will provision the initial content of the new virtual portal. Once out of the box, that script will deploy a set of basic administration portlets including login, self-care, search portlets, and the document management portlets. The default content can be modified easily by changing the provided XML Access script. The script can be found in the WAS directory in installedApps\<hostname>\wps.ear\wps.war\virtualportal.
Besides the "manage virtual portal" portlet, it is also possible to use a set of configuration tasks in order to manage virtual portals.
SummaryVirtual portal is an out-of-the-box feature of WebSphere Portal 5.1. The feature has a strong emphasis on an efficient implementation, which addresses the need for isolation as well as for sharing between virtual portals.
For further reading, you can find additional information in the virtual portal section of the InfoCenter at: http://publib.boulder.ibm.com/pvc/wp/510/ent/en/InfoCenter/index.html.
|
