IBM WebSphere Portal provides a single point of interaction for users and administrators. It provides a common look-and-feel throughout the portal, and a standardized application programming model, which you can leverage to integrate various backend systems into a common user experience.
Suppose you need to provide portals to several, independent user communities. Each user population wants its own unique, distinguished look-and-feel, and to be able to work independently from any other communities you manage; they want to have their "own" WebSphere Portal server. To support each community, you could install individual WebSphere Portal servers. However, WebSphere Portal V5.1 supports a much more efficient methodology in which you create multiple virtual portals on a single server. Each virtual portal is a separate logical partition within the single, common WebSphere Portal installation.
Support for virtual portals is a standard feature in WebSphere Portal V5.1. You can easily create virtual portals on any standard WebSphere Portal installation whenever additional logical portal instances are needed. Creating virtual portals can be created on demand, without special enablement or additional licensing.
All virtual portals on the same WebSphere Portal installation exist within a single common Java™ Virtual Machine (JVM). Sharing the JVM helps to minimize memory consumption and enables the sharing of applications and data among multiple virtual portals. Of course, failure protection between applications is limited, due to the common JVM.
Figure 1 shows the key features which are exposed by virtual portals:
- You access a virtual portal using a specific URL mapping, which is associated with that virtual portal.
- You can customize virtual portals to expose a unique look-and-feel. You can assign different themes and skins to different virtual portals.
- Scoped and shared WebSphere Portal resources enable isolation between the content of different virtual portals.
- Each virtual portal can have its own distinct user population.
- For administration of virtual portals, the delegation model of Portal access control is leveraged. Within a virtual portal, sub-administrators can apply access control independently.
- Login and selfcare are implemented as portlets and can be customized for a specific virtual portal.
- A new administration portlet exposes a user interface to manage virtual portals.
Figure 1. Key features of virtual portals
The following sections explain these concepts in more detail.
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. By default, the associated theme applies to all pages created within that virtual portal, and for the anonymous pages of a virtual portal, including the login and enrollment page. Therefore, you provide a consistent user experience. WebSphere Portal supports this paradigm by replacing the screens, which had been used in previous releases, with normal pages and portlets. In WebSphere Portal V5.1, each virtual portal has its own login and selfcare page.
Administrators will find the usual administration portlets within each virtual portal. They can these portlets to customize its appearance. Figure 2 illustrates multiple virtual portals with different themes.
Figure 2. Using different themes for different virtual portals
Virtual portals are peers with each other. Each virtual portal has its own navigation with its own context root, its own instances of administration portlets, and its own set of pages. In addition to the login page (mentioned earlier), each has its own welcome, favorites, My Portal, and the anonymous pages.
When sending a request to portal, the URL needs to specify which virtual portal should be accessed. Friendly URL mappings are applied. Each virtual portal has a specific URL mapping which references the portal's content root. That mapping is defined and created during the initialization of the virtual portal.
For example, a friendly URL for a virtual portal might look like this:
You can create additional URL mappings to pages within the virtual portal at any time in exactly the same way as you would have done in a standard WebSphere Portal V5.0 installation. For more information on the use of URL mappings, see the Administering =>Portal configuration section of the WebSphere Portal InfoCenter.
If no URL mapping is specified, the user is directed to a default virtual portal, which is the one created during installation of WebSphere Portal. In the case that an invalid URL mapping is used, the user is also directed to the default virtual portal.
Depending on which URL mapping, WebSphere Portal sets an internal Virtual Portal Context. All user activity executes within the context of that virtual portal. The current context determines which content is visible to the user.
Figure 3 shows how to access virtual portal content using URL mappings.
Figure 3. Accessing portal content using URL mappings
WebSphere Portal V5.1 supports the requirement to isolate the content of individual virtual portals, while still allow the sharing of applications. It supports this requirement my scoping or sharing resource types. Each type of resource is designated to have one of the following two attributes:
- Scoped to a particular virtual portal
- Shared among all virtual portals of an installation
Scoped resources belong to exactly one virtual portal -- that is the virtual portal in which they have been created. To use 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 all scoped resource types. The scoping of these resource types is enforced by WebSphere Portal. The internal object ID of each scoped resource includes a reference to the virtual portal in which it is valid. WebSphere Portal can compare this information with the current virtual portal context, and decide if a particular resource is to be visible or should be ignored. This filtering of resources cannot be modified; you cannot override this behavior using access control.
Shared resources are available to the entire WebSphere Portal installation and can, therefore, be used by all virtual portals. Portlet definitions, portlet applications, web modules, URL mappings, Web Services for Remote Portlets (WSRP) producers, themes, and skins are all shared resource types.
However, you can apply WebSphere Portal access control to limit the usage of shared resources to certain virtual portals. To limit usage, you grant permissions for users of specify virtual portals to the desired shared resource or resources.
Unique names of resources 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 names of shared resources must be unique, within the WebSphere Portal installation. When used for a scoped resource, the same name can be re-used in multiple virtual portals.
This behavior is quite convenient, because it lets you use common names for similar pages in different virtual portals. WebSphere Portal V5.1 assigns several unique names by default:
- The content root of each virtual portal is identified by
- Several pages created individually for every virtual portal have a common name:
- My Portal (
- Administration (
- Login page (
- Enrollment page (
- Page properties (
- My Portal (
You can reference shared resources such as portlet applications by the same name throughout the installation. WebSphere Portal V5.1 uses these unique names by default:
- Login Portlet (
- Enrollment Portlet (
- The unique names, which are associated with Administration Portlets are documented in the WebSphere Portal InfoCenter.
The URL mapping which points to the context root of a virtual portal has a unique name, as well. It is composed of the wps.vp.prefix followed by the internal object ID of the virtual portal. URL mappings are shared; but the name is unique throughout the installation.
For more information on unique names see the Unique names section of the WebSphere Portal V5.1 InfoCenter.
When you try to share portlets across virtual portals, an important impact of scoping and sharing surfaces. Because portlet applications are shared resources, their properties will be common across the entire installation. Therefore,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 must clone the portlet application. Each virtual portal can use its own clone with its 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. Figure 4 illustrates the use of portlet preferences related to virtual portals.
Figure 4. Using portlet properties
All WebSphere Portal property files apply to the entire installation. You cannot define a specific setting for an individual virtual portal. The same is true for portlet services and for the credential vault. Any public credential in the credential vault is visible to all virtual portals.
The Content and Document Management portlets for Portal Document Manager and Web Content Management are not scoped to a virtual portal. You can, however, limit the content which is visible using access control or different configurations in the portlet properties; for example, you could use a different Content Library for each virtual portal.
The scoping constructs described above isolate WebSphere Portal resources. The construct known as a realm lets you create an individual user community for a virtual portal. A realm aggregates a set of users within a user repository, such as 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.
In WebSphere Portal V5.1, you can associate a virtual portal with a specific realm. 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, realm membership can be used to strictly separate user populations for different virtual portals. Even a
wpsadmin will not be able to log in to a virtual portal, unless the
wpsadmin is a member of the corresponding realm. This security check cannot be overwritten.
However, multiple virtual portals can share the same user population by specifying the same realm relationship. Realms can overlap, so that a user can be a member of more than one realm.
User and group management operations also only affect the user population associated with a realm.
In order to leverage realms, you configure the WebSphere Member Manager User Registry (WMMUR) as a custom user registry. You can choose WMMUR when you enable security. You can use either of these alternative WebSphere Portal supported configuration tasks:
enable-security-wmmur-ldap, which activates WebSphere Portal security with WMMUR using an LDAP user repository
enable-security-wmmur-db, which activates WebSphere Portal security using a WMM database as the user repository
Unlike groups, realms are defined within the WebSphere Member Manager configuration, and are not part of a user registry itself. WebSphere Member Manager exposes several XML files, which you need to edit:
- WMM.xml is the basic configuration file of WMM. This file is used to define the used user repositories
- WMMUR.xml is the place, where realms are defined and the where parts of user repositories are mapped to realms.
For more information on working with these files, see the WebSphere Portal V5.1 InfoCenter.
As an alternative to using WebSphere Member Manager, you can configure WebSphere Application Server LDAP security mode using the
enable-security-ldap task. All virtual portals will have the same user population with this configuration.
Two kinds of administrators are involved in a virtual portal environment. The master administrator, who is responsible for the entire installation, has administration privileges for WebSphere Portal. This person creates virtual portals and typically manages the shared resources. The master administrator also owns the responsibility for installing portlets, themes, skins, and other resources. Typically, this kind of administrative work is performed by a service provider, which owns a WebSphere Portal installation and is hosting multiple virtual portals.
When the master administrator creates a new virtual portal, he or she delegates the administration of the new virtual portal to a group of sub-administrators. The sub-administrator manages the pages, portlet entities, and the users and groups within the virtual portal. The master-administrator determines which roles are delegated to the sub-administrator.
The sub-administrator typically represents the tenant hosted by the owner of the WebSphere Portal installation. Such a tenant can be an independent company, a specific organizational unit, or some kind of franchising business.
By default, these roles are assigned automatically:
- Admin role to the VP's context root
- Admin role on the URL mapping
- Editor role for the VP's portlet entities
The master administrator needs to set up any additional required roles. Typically these additional role definitions include editor and security administrator permissions for the users and groups for the virtual portal.
Because all virtual portals run in the same JVM, it is unlikely that sub-administrators will be allowed to deploy their own code into their virtual portal. A risk exists that uncertified, poorly written or malicious code could impact the overall stability of the installation. If an individual virtual portal needs to integrate with private portlets, the preferred solution would be to aggregate remote portlet services using WSRP.
Figure 5 illustrates the delegated administration model as provided by WebSphere Portal access control.
Figure 5: Leveraging delegated administration provided by Portal access control
As mentioned earlier, a typical scenario for applying virtual portals is a service provider, who owns a WebSphere Portal installation and provides portal services to his tenants. Whenever a new tenant requests a virtual portal, the service provider creates another instance and delegate the administration of the new virtual portal to the tenant's administrator. To enable this task, WebSphere Portal provides a new administration portlet, which enables the master administrator to create and remove virtual portals. To create a virtual portal, the master administrator specifies a set of properties (such as title, realm, friendly URL Mapping, default theme) and designates the group of sub-administrators.
This Manage Virtual Portal portlet provides two additional capabilities. During the creation process, an XML script executes, using the XML configuration interface, that provisions the initial content of the new virtual portal. A script called
InitVirtualPortal.xml (provided by WebSphere Portal) deploys certain administration pages and portlets (login, selfcare, search portlets and the document management portlets). You could modify the default content of a new virtual portal by changing this XML script. Therefore, the owner of a WebSphere Portal installation can add his own portlet and layout information to the default navigation of any new virtual portal.
After the XML script executes, the administration portlet applies these access control roles to the created content:
- The virtual portal sub-administrator group is granted the administration role to the virtual portal's content root.
- The sub-administrators are granted rights on certain portlets. The choice of action set which should be applied to the designated portlets is specified in the edit mode of the virtual portal administration portlets:
- The type of role can be defined by setting the value of the portlet property
actionSetName. The default is
- The portlet property
portletListNeedAccesslists the unique names of all those portlets to which the action set should be applied. The default includes all portlets, which are deployed in the XML script mentioned above.
- The type of role can be defined by setting the value of the portlet property
Usually, the master administrator needs to make additional role assignments based on the business need of the sub-administrators.
Figure 6 shows the interface which the master administrator uses to create a new virtual portal.
Figure 6.: The Manage Virtual Portal portlet
When the master administrator deletes a virtual portal, the portlet also deletes all content that is scoped to that virtual portal. Shared resources are not be affected.
In addition to using the Manage Virtual Portal portlet, the master administrator can also use a set of configuration tasks tasks to create new virtual portals. These tasks provide functionality which is similar to the "Manage Virtual Portal" portlet. However, there are slight changes when creating a virtual portal, because the corresponding configuration task does not create any content or access control roles within the new virtual portal.
The XML script, which WebSphere Portal provides,
InitVirtualPortal.xml, needs to be invoked in a separated step, using the XML configuration interface.
The usage of the XML configuration interface does not really change. Existing XML scripts will continue to work. The major difference is that XML scripts will only be executed within the context of a particular virtual portal. In other words, XML scripts can only be imported into a single virtual portal. If you want to export the contents of multiple virtual portals, you need to do this in multiple steps; that is, one virtual portal at a time. When you call the XML configuration interface, you specify the virtual portal you want to work with using the associated friendly URL mapping:
xmlaccess -in myscript.xml -user user -pwd pwd -url myhost:9081/wps/config/URL_mapping_of_VP
When you use the WebSphere Portal scripting interface, you set the current virtual portal context before logging in. All of the following scripting commands will work in that context until the user logs out. Again, the friendly URL mapping is used to specify the virtual portal.
This article was intended to help you understand the virtual portals basic. It provides background information to help you plan a portal installation with multiple virtual portals, and to deal with these typical questions:
- What kind of customization is necessary? Do you need to create and apply different themes for each virtual portal?
- How will you set up the URL mappings to access virtual portals?
- What kind of privileges will a virtual portal administrator need?
- Will you need distinct user communities for each virtual portal?
- Will virtual portals be managed using the new administration portlet, or will you use the configuration tasks?
- What initial content will a new virtual portal have?
Virtual portal support is an out-of-the-box feature in WebSphere Portal V5.1. The intent is to provide an efficient product implementation, which is based on a common WebSphere Portal installation and a single JVM used by all virtual portals.
Each virtual portal has its own content root and its own navigation. Individual themes and login pages let you create a very specific look and feel. URL mappings are used to access a specific virtual portal within the installation. Depending on the resource type, the content is either strictly isolated to a specific virtual portal, or it can be shared and managed through access control. The user community of a particular virtual portal can be configured as a realm.
For more information, see Administering => Multiple virtual portals in the WebSphere Portal V5.1 InfoCenter. For details on configuring WebSphere Member Manager, see the section called Enable security => Using multiple realms.
- WebSphere Portal product documentation, including the V5.1 InfoCenter.