Taking a step toward virtual portals in WebSphere Portal V5

IBM ® WebSphere® Portal is a scalable framework capable of hosting a very large, personalized portal for millions of users, but that model is not the only portal model. Some businesses are very interested in creating several independent portals for diverse groups of end users. This paper discusses how to create a set of independent portals all hosted on a single or clustered WebSphere Portal installation.


John Binder (debinder@us.ibm.com), Senior Consultant, IBM Software Services for WebSphere, IBM

Author photo: John DebinderJohn De Binder is a senior consultant with the World Wide Portal Practice in IBM Software Services for WebSphere (ISSW) in Raleigh, North Carolina.

Fetchi Chen (fchen@us.ibm.com), Senior Consultant, IBM Software Services for Lotus , IBM

Author photo: Fetchi ChenFetchi Chen is a Senior Consultant with the Technology Group in IBM Software Services for Lotus (ISSL) in Austin, Texas.

16 June 2004


The following list is an example set of requirements that would motivate an IT department to implement these portals in a single, scalable installation of WebSphere Portal V5.

  • Multiple user populations belonging to different organizational units or companies
  • A desire to offer each group a different user experience, including different:
    • Anonymous pages
    • Themes
    • Page layouts
  • Allow all of these end users to collaborate using a single Sametime community
  • Many common portlets
  • Many common requirements for the infrastructure (common services)
  • A desire to have a single, large and scaled infrastructure instead of many smaller sets of servers for each portal

We refer to these independent portals within WebSphere Portal as virtual portals. The term virtual is used because the typical assumption is that a WebSphere Portal installation includes a single portal; these independent portals extend the typical environment.

The concept of virtual portals has been a requirement for some time now. Many changes in WebSphere Portal V5 have been developed to support this functionality. Although the product documentation does not yet officially describe the virtual portal concept, or provide procedures for creating them, the V5 release includes support which can be used to begin implementing virtual portals.

Overview of virtual portals

If you look closely at the new default theme for WebSphere Portal V5 you can see some building blocks for virtual portals.

The new toolbar at the top of the portal page enables you to provide links to several different areas of your portal. It already contains links to the default portal, the administration pages, and the user profile editor.

The Manage Pages administration portlet lets you create several content roots. Each content root defines an independent hierarchy of pages within the portal infrastructure. These independent hierarchies form the basis for virtual portals. In effect, the MyPortal and Administration content roots are examples of virtual portals. The development team often implements new capabilities for their own use in the administration pages that are hints of new capabilities that will soon be offered as documented capabilities in the product.

Now, look at two key features in WebSphere Portal V5 that you can use to start implementing virtual portals. Following this description, the article takes you through specific steps to define multiple virtual portals within a single portal installation.

Content root

In previous versions of WebSphere Portal you were only allowed to create a single hierarchy of portal pages. In the new Manage Pages administration portlet you can now define multiple, independent hierarchies of portal pages. The top of each hierarchy is known as a content root. While visiting pages in one hierarchy, you do not see links to the pages in the other hierarchies within your navigation.

URL mapping

Before V5, it was rather difficult to create a URL from an outside source to a particular page within the portal. Portal URLs are full of unique identifiers that represent specific pages and portlets. These URLs are normally created with tags or APIs that are only available from within the portal framework.

URL mapping enables you to define your own fixed URL schema which can be easily used outside of the portal framework. You can then create user friendly URLs, which can be mapped to any specific page in any of the content roots.

Steps to implement virtual portals

Now you see how to use these new features to implement a set of virtual portals. The high level tasks for implementing a virtual portal are to:

  1. Define a new content root
  2. Define URL mappings
  3. Change your theme to provide a login path unique to the virtual portal

Defining a new content root

You need to define a new content root for each virtual portal. In this section, you see how to define two new content roots; each root contains the hierarchy of pages for its virtual portal.

  1. Logon to the portal as an administrator.
  2. Click the Administration link in the toolbar.
  3. Select the Manage Pages portlet; that is, on the left navigation, click Manage Pages.
  4. Ensure the content roots are displayed.
    Figure 1. Content root list
    Content root list
  5. Click the New label button.

    Title: Virtual Portal
    Theme: Engineering

    Figure 2. Virtual Portal 1 definition
    Virtual Portal 1 definition
  6. Click OK.
  7. Select Virtual Portal 1.
  8. Create a Welcome page under Virtual Portal 1.
    Figure 3. Welcome page definition
    Welcome page definition
  9. Click OK.
  10. Place two portlets on the Welcome page; for example, About WebSphere Portal and World Clock, as shown below.
    Figure 4. Adding two portlets to the page
    Adding two portlets to the page
  11. Click Done.
  12. Create a Work page.
    Figure 5. Creating the Work page
    Creating the Work page
  13. Click OK.
  14. Place two portlets on the Work page; for example, QuickLinks and Bookmarks.
    Figure 6. Adding two portlets to the Work page
    Adding two portlets to the Work page
  15. Click Done.

    Virtual Portal 1 should now have two pages defined, as shown below.

    Figure 7. Virtual Portal 1 with two pages
    Virtual Portal 1 with two pages

Now repeat the last few steps to create the Virtual Portal 2 content root with a different theme and two similar pages. The following shows the two content roots, Virtual Portal 1 and Virtual Portal 2.

Figure 8. Revised content roots list with both virtual portals
Revised content roots list

Defining the URL mappings

You have defined several new portal pages. How do you display them in a browser? Because these new pages have been defined in separate page hierarchies, the navigation for the default portal does not include links to them.

In order to display them, you must define new portal URLs and associate them with the new virtual portals. When you choose a content root, the theme displays navigation links to the rest of the pages you have defined in that hierarchy.

  1. Logon to the portal as an administrator.
  2. Click the Administration link in the toolbar.
  3. Click the Portal Settings link.
  4. Click the URL Mapping link.
  5. Click New Context.
  6. Define a link to the first virtual portal (VPortal1).
  7. Map this link to Virtual Portal 1 using the Edit Mapping icon Edit Mapping icon .
  8. Define a link to the second virtual portal (VPortal2).
  9. Map this link to Virtual Portal 2 using the Edit Mapping icon Edit Mapping icon .

The URL mappings should look like this:

Figure 9. URL mappings for the two context roots
URL mappings for the two context roots

Navigating to the two virtual portals

So far, you have now created both the virtual portals and mapped new URLs to them. In order to use these new URL mappings, you need to know how to build a complete URL. The complete URL must begin with either the public or protected portal URI path. The default public URI path is /wps/portal and the default protected URI path is /wps/myportal. The URL mapping labels defined here follow this URI.

  1. Type the following into your browser's address bar to display the Welcome page for Virtual Portal 1. Notice that a link to the Work page is displayed in the navigation bar.
  2. Log in as the same user that created the virtual portal pages.

    Important: If you have changed the default protected URI path for your portal use that instead of /wps/myportal.

  3. Type the following into your browser's address bar to display the Welcome page for Virtual Portal 2. A link to the Work page displays in the navigation bar.

Defining access control for the pages

So far you have been able to see the new virtual portals because your userid created them. Now you see how to differentiate anonymous content from protected content. You define the Welcome pages in both virtual portals to be viewable by anyone who can find the virtual portals, and you define the Work page to be restricted to only those users who have authenticated with the portal.

  1. Logon to the portal as an administrator.
  2. Click the Administration link in the toolbar.
  3. Click the Manage Pages link and display the content roots.
  4. Click the Set Page Permission icon Page permission icon for the Virtual Portal 1 label.
  5. Click the Edit Role icon Edit role icon for the Privileged User role.
  6. Click the Add action.
  7. Select the all Authenticated Users group.All pages under Virtual Portal 1 inherit this access.

    Tip: You could create different groups in LDAP and associate each virtual portal with a different group.

  8. Go back to the Manage Pages portlet and display the Content Roots again.
  9. Select Virtual Portal 1 to display the pages under that label.
  10. Click the Set Page Permission icon Page permission icon for the Welcome page.
  11. Click the Edit Role icon Edit role icon for the User role.
  12. Click the Add action.
  13. Select the anonymous portal user group.
  14. Repeat the above steps for Virtual Portal 2.

Now the Welcome page can be displayed by anonymous users. Try the following links:


If you use one of the following links, and you log in as a defined user, then you can see both pages in the virtual portal.


Login changes

Now that you have defined anonymous content for your virtual portals, you need to allow users to login from within the virtual portal. Currently the login link in the toolbar at the top of the page is a direct link to the login screen. The portal automatically adds parameters to this URL to specify the theme to use for the login screen. It also remembers the page the user first requested and redirects them back to that page. Therefore, with these defaults the user sees the login screen displayed under the theme that matches the virtual portal that they are working with and they are redirected back to the anonymous page for the virtual portal.

Theme changes

Next, you need to change the themes to provide links to your virtual portals. Because the current text is static, on the theme for each virtual portal, you can change the text for My Portal to Virtual Portal 1 or Virtual Portal 2. For the Administration theme, you can assume that the admin user has permission to access both virtual portals and place links from the URL mappings for both virtual portals into the admin theme. This is also a safe assumption if both virtual portals have anonymous content.

Modifying Logout

By default the log out link is a reference to the LogoutUser command, which redirects the user to the default portal. You might think this is hardcoded to be My Portal, but it is actually just a screen that is mapped to the LoggedOut screen name. This is mapped to the Home screen by default and can be changed in the Finder Service properties file.


There is currently a bug in the default theme that displays both the place bar and the page bar navigation items for the default portal. You can fix this situation by making the highlighted changes below in the Default.jsp.

<%-- Don't show navigation in solo mode --%>
<wps:if portletSolo="no" screen="Home,LoggedIn"> <%@ include file="./PlaceBarInclude.jsp" %>
  <%@ include file="./PageBarInclude.jsp" %>

What we really need is a way to specify a parameter on the LogoutUser command to identify the URL to be used when redirecting the user after logout. If you can get access to the LogoutUser.java source code, you can change it to accept this parameter and re-deploy the wps.ear.


The following describes limitations of this implementation.

Single LDAP

WebSphere Application Server only allows a connection to a single LDAP directory. This means that there is only a single pool of users and groups in the LDAP directory to work with and that there can be only one set of super Portal administrators. This limitation can be somewhat mitigated by delegating administrative authority to each page hierarchy to a different group of users. All these users must have authority to see and install portlets because there is only one global set of portlets and portlet applications.

All portals must use the same common domain suffix if they want to make use of the single sign-on feature provided by WebSphere Application Server.

Access control

Not all resources can be protected and limited to a particular virtual portal. For example, themes and skins will be made available to all virtual portals without restrictions.

Common services

Credential Vault, Portlet Services, and Portal Services are common for an entire installation. They cannot be scoped to a particular virtual portal.

Global settings

The settings which are defined in the portal properties files apply for the entire installation. It is not possible to have specific settings for particular virtual portals.

Automatic theme selection for screens

Screens are global objects and can be referenced from any page in any virtual portal. Therefore, screens do not have any themes associated with them. The assumption is that the screen should be displayed under the theme associated with the last page displayed.

When the user requests a protected page and is redirected to the login screen there is no established previous page or theme. In this case, the portal currently defaults to using the default portal theme. It may be possible in future versions of the portal to determine the theme associated with the requested URL and use that theme for the login screen.


WebSphere Portal Version 5 begins to fulfill the requirement for virtual portals. The simple example described here illustrates techniques you could use to begin implementing your own virtual portals. Each of these portals can have a different set of anonymous pages and a different set of portal themes, and yet all be supported by a single installation of WebSphere Portal.

The current infrastructure might not support everything you want to provide for your users, but it does let you get started. If there are additional things you would like to see in the product please submit your requirements to IBM.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Taking a step toward virtual portals in WebSphere Portal V5