Plan for virtual portals

 

+

Search Tips   |   Advanced Search

 

  1. Overview
  2. Manage the user population for virtual portals
  3. Administer virtual portals
  4. Shaping the user experience
  5. Alternative concepts for virtual portals on WebSphere Portal

 

Overview

A single portal installation can support up to 150 virtual portals.

Separation between virtual portals is achieved by scoping the portal resources of the virtual portals, making portal resources available uniquely and separately to individual virtual portals and their users.

A portal resource that is scoped for virtual portals exists individually for each virtual portal. It has an identification that is unique within the entire portal installation. The resource is available only in one particular virtual portal. Consequently, you can customize such resources for each virtual portal independently.

For example, resource_A is scoped for the virtual portals...

...as...

Customizing resource_A_VP_1 does not affect resource_A_VP_2 and resource_A_VP_3.

A portal resource that is not scoped for virtual portals is shared between all virtual portals. Consequently, if you customize this resource, this will affect that resource in all virtual portals equally.

IBM WebSphere Portal scopes some portal resources for virtual portals. This means that these resources exist separately for each virtual portal.

Other resources are common for all virtual portals in a portal installation. However, you can scope some of these resources:

The user population can be scoped to one or more specific virtual portals.

 

Portal resources that are scoped for virtual portals

WebSphere Portal has the following portal resources scoped internally for virtual portals:

Scoped resources are only available for the virtual portal for which they are defined. They are well isolated from other virtual portals. Scoped resources cannot be shared with other virtual portals. They are not visible or accessible outside of the virtual portal for which they have been created. This behavior cannot be changed by any Portal Access Control settings.

The following rules apply:

 

Portal resources that you can separate for virtual portals by using Portal Access Control

There are some portal resources that are not scoped internally for a particular virtual portal. These resources are shared among all virtual portals of the entire installation. However, as a master administrator you can yourself separate such portal resources for the virtual portals.

To do this, use Portal Access Control and the access rights portlets to set up the appropriate access rights for users on the resources of each virtual portal as required.

You can separate these resources for individual virtual portals by using Portal Access Control. When you do this, apply special care. It can be of benefit to document the relationships between the users and the virtual portals.

 

Portal resources that cannot be separated for virtual portals

There are some types of portal resources that are not scoped to a particular virtual portal, and you cannot separate them yourself by using Portal Access Control. The following list shows portal resources that you cannot separate for virtual portals:

Examples:

  1. Themes and skins can be accessed by all subadministrators who have the access right to apply themes and skins to the pages that they can administer, regardless of which virtual portal the subadministrators are responsible for.

  2. If a subadministrator imports a new template into one virtual portal, this template will appear in the application template library of all virtual portals.

 

Separating portlets and portlet applications

Separating portlet applications

Portlet applications are not scoped for virtual portals. Therefore, the configuration settings that you set for a portlet application by using the Manage Applications portlet apply to that portlet application in all virtual portals. If you need different configurations for a portlet application between virtual portals, create a copy of the portlet application, and configure the copied portlet application as required.

 

Separating portlets

Portlets are separate portal resources, but they are not scoped for each separate virtual portal. However, each portlet in a virtual portal shares its portlet application on the initial portal installation with its siblings on the other virtual portals. Therefore the following configuration settings set for a portlet apply to that portlet in all virtual portals:

If you need different configurations for a portlet between virtual portals, create a copy of the portlet, and configure the copied portlet as required.

 

Scoping portlet instances

Portlet instances are scoped to the virtual portals.

The configuration settings that you set for a portlet by using the Personalize or Edit shared settings mode of the portlet apply only to that individual portlet instance on that individual page.

 

Special case: Scoping unique names

Unique names that you apply to portal resources represent a special case with regards to scoping. Unique names are attributes to portal resources. Therefore, whether a unique name is scoped to a virtual portal or not is determined by whether the portal resource to which the unique name applies is scoped or not:

 

Example for a scoped unique name

Each virtual portal has its own separate login page. Therefore you can assign the same identical unique name to all login pages for all virtual portals. The unique name that you give to the login page of a specific virtual portal applies only within that portal. It cannot be administered in a different virtual portal that has the same unique name for its login page.

 

Example for a unique name that is not scoped

Portlet applications are not scoped but shared between all virtual portals. You can assign a unique name to the portlet application. You can reference that portlet application by that unique name throughout the portal installation with all virtual portals.

 

Manage the user population for virtual portals

There are two basic options for the management of user populations for your virtual portals:

  1. Virtual Member Manager (VMM)

    VMM is also known as the Federated Repository.

    Use VMM to...

    • Configure separate user populations for each of your virtual portals.

    • Use a common user population with the VMM for all your virtual portals.

      All users can access all virtual portals, unless their access rights are explicitly restricted by portal access control settings.

  2. LDAP

    If a single common user repository is sufficient for all virtual portals within your installation, you can continue to use an LDAP in your virtual portal setup. This is the simpler one of the two options.

    With this configuration the entire portal installation and all virtual portals share a common user population, which is defined in a single user repository. In this case all users of that user population can access all virtual portals, unless their access rights are explicitly restricted by portal access control settings.

    In order to achieve access restrictions for specific virtual portals, use the Portal Access Control portlets. You define user groups and assign to them the access rights to the resources of each virtual portal.

For WebSphere Portal installations, the Federated Repository option offers you more flexibility for the user management of virtual portals as stand-alone WAS LDAP.

By using the VMM you can limit the usage of a particular virtual portal to a specific user population. This is achieved by introducing the concept of realms.

 

Realms and VMM

A realm is a group of users from one or more user registries that form a coherent group within IBM WebSphere Portal.

A realm must be mapped to a virtual portal to allow the defined users to log in to the virtual portal. When configuring realm support, you can perform these steps for each base entry that exists in your LDAP and/or database user registry to create multiple realm support.

A virtual portal can only be accessed by members of its associated user population. By using Portal Access Control you can assign and restrict access rights within the user population of a virtual portal to the resources of that virtual portal. However, Portal Access Control cannot overwrite the predefined assignment of a particular user population to their virtual portal. Consequently, you cannot use Portal Access Control to assign access rights that cross the separation between virtual portals. For example, you cannot use the Portal Access Control of a virtual portal VP_A to give a user User_A_1 of that portal access to resources of another virtual portal VP_B.

The following conditions apply:

 

Preparing the user populations for your virtual portals

Configure VMM and realms before creating virtual portals.

Each realm must specify the base entries that belong to the user population represented by the realm.

In addition to the realms created to define the user populations of the individual virtual portals, create a super realm. This super realm spans all other realms and contains all the users of those other realms; it is also known as the default realm.

By default WebSphere Portal is configured with Federated Repositories as the user registry provider. By default only the super realm, or default realm, is configured. After you have configured your portal instance against your user backend repositories use tasks provided by the portal to configure the realms that the VMM provides.

 

Configure a common user population for all virtual portals

In a simple setup use the VMM together with a common user repository.

This user repository is represented by a single realm, and used by all virtual portals. In this case, all virtual portals use a common realm and a common user repository. This configuration provides no separation between the users of the different virtual portals.

WebSphere Portal still supports the WAS LDAP custom user registry that previous versions of WebSphere Portal used. You can configure it as alternative. Again, this configuration uses a common user repository for all virtual portals without separation between the users of the different virtual portals.

 

Configure separate user populations for the individual virtual portals

To have the users of your virtual portals separated, you have to apply the more advanced setup by using Federated Repositories and configuring separate realms for your virtual portals. When users access a virtual portal, the portal installation selects the appropriate realm based on the current virtual portal context. Within a virtual portal, only users of that corresponding realm are "visible". The administrator of a particular virtual portal can only give access rights to users and groups in the population of that virtual portal. Therefore, when you create a virtual portal, the realm that represents the population of the new virtual portal must be a subset of the realm used by your portal installation.

This separation of user populations between virtual portals works only with Federated Repositories.

The portal supports separate realms and user repositories for virtual portals only when you use the Federated Repositories.

When you use the Federated Repositories, you can separate user groups and administrative users by configuring your virtual portals according to your business requirements. You do this based on the following relationships between user repositories, realms, and virtual portals:

For example, you can set up the following configurations:

The Portal Access Control administration in the Resource Permissions portlet shows users from different realms who have role mappings on shared resources by their object IDs. Therefore, apply special care and consideration when deleting such portal resources: Do not delete resources on which users from other realms have role mappings, if they are required in other virtual portals. This applies to members of roles on portal resources that cannot be scoped and are therefore shared between the virtual portals.

Role members who belong to the realm of your local virtual portal are displayed as usual, but role members who belong to different realms are displayed in a different manner:

You find the list of role members in the portal information center under...

Administration | Access | Resource | Permissions | Select Resource Type | Assigning Access for a resource | Edit Role

...under the first column Members in the Role.

 

Grant virtual portal administrators access to Web content libraries

Virtual portal administrators do not automatically have access to work with Web content libraries when using the administration portlet. To enable a virtual portal administrator to work with Web content libraries you will need to assign them access to either the JCR content root node or individual Web content libraries:

 

Planning considerations for administering virtual portals

Depending on the option that you selected during your portal installation, you create virtual portals and their content by different ways:

 

Portal Access Control with virtual portals

You can scope some portal resources for your virtual portals by using portal administration and Portal Access Control. For example, this applies to portlet applications.

These resources are available to all virtual portals. You can scope these resources to specific virtual portals by limiting their accessibility to the user populations of the required virtual portals. To do this, you use Portal Access Control. Resources that you scoped this way for one virtual portal cannot be accessed from other virtual portals.

Portal Access Control provides a flexible concept to grant certain users or user groups access privileges to specific pages and other resources of a portal.

A super administrator can delegate a subset of the administration privileges to other administrative users. Use this flexibility to enable separation between different virtual portals in the following ways:

The inheritance concept of Portal Access Control allows this setup. The combination of access rights that a subadministrator has on portal resources and on users and groups defines the scope of the virtual portal of that subadministrator:

This way, each virtual portal represents a certain sub area of the main portal and can be managed individually.

 

The master administrator

The master administrator user ID is created during the initial installation of WebSphere Portal with the role "administrator" on the portal...

This administrator is also the master administrator of the initial portal installation and all virtual portals that are created. This master administrator is created with all necessary access rights for administering tasks related to the initial portal and the virtual portals.

The master administrator has the necessary privileges to perform the tasks related to managing virtual portals. These tasks can be performed by using either the administration portlet Virtual Portal Manager portlet or the provided configuration tasks.

The Virtual Portal Manager portlet is installed as part of the initial portal installation. Use this portlet to create, modify and delete virtual portals.

The master administrator defines the user population of each virtual portal. To separate the user populations of the individual virtual portals, the master administrator can either use the User and Group Permissions portlet of Portal Access Control or can define realms in the VMM configuration files.

Before you create a virtual portal, you define a group of subadministrators.

When you create the virtual portal, a default set of roles and access rights is assigned to this group. As the master administrator you can change these default assignments and delegate administration of individual virtual portals to subadministrators by using the Resource Permissions portlet that is part of the Portal Access Control.

When you create a virtual portal, it is filled with a default set of portal pages and resources. Content of a virtual portal can be further enhanced by either of the following ways:

Typically, only the master administrator should have the access rights for performing the following tasks:

Do not grant the subadministrators of virtual portals the access rights to perform any installation related tasks, such as installation of portlets or themes. All virtual portals share a common JVM. Therefore it is important to restrict the administration privileges of the virtual portal subadministrators and prevent them from installing their own code artefacts, such as themes or portlets. Unstable or malicious code that is introduced on one virtual portal can destabilize the entire portal installation and thereby all other virtual portals.

A flexible way to introduce virtual portal specific portlets without impacting any other virtual portal is to use Web services for remote portlets (WSRP), which provides portlets on a remote machine and then have the virtual portals consume those portlets so that users can access them remotely.

 

Subadministrators of a virtual portal and their access roles and rights

When you create the virtual portal by using the Virtual Portal Manager portlet, you select a user group of subadministrators that you want to be responsible for the administration of the new virtual portal. During creation of the new virtual portal the Virtual Portal Manager portlet assigns the following default set of necessary access rights on the virtual portal to the subadministrator group specified:

As the subadministrators have the Editor role access rights on the administration portlets of their virtual portal, they can use these administration portlets to perform administrative tasks on the virtual portal. To change the default Editor access right for the subadministrators on the administrative portlets or the list of portlets globally and before you create virtual portals, configure the Virtual Portal Manager portlet accordingly.

See Preconfiguring the subadministrators for virtual portals.

You can also assign additional access rights on portal resources to the virtual portal subadministrators. For example, you might want to add the following access rights:

To assign additional access rights to the subadministrators after creating a virtual portal, use the master administrator user ID of your portal installation and modify those access rights for them manually in Portal Access Control. To do this, use the User and Group Permissions portlet, the Resource Permissions portlet, the XML configuration interface, or the Portal Scripting Interface. The consequences differ, depending on where you make the updates:

 

End users of a virtual portal and their access roles and rights

When you create a virtual portal, be aware of the following implications:

To change these default roles and the access rights for the users, you can do this by one of the following ways:

 

Content of a virtual portal

When you create the virtual portal by using the Virtual Portal Manager portlet, the portlet invokes an XML configuration interface script that creates the initial content of the new virtual portal. The content of a virtual portal is similar to that of a full portal installation, but some administration portlets that manage global portal settings are not included in the default content of virtual portals. For example, the administration portlet Virtual Portal Manager is installed as part of the initial portal installation only. It is not part of the default content of virtual portals that you create. You can only use it in the initial portal installation.

Once the content has been created, the Virtual Portal Manager portlet grants the following set of default roles and access rights to the subadministrators of the virtual portal:

You can modify the roles and access rights for the subadministrators of a virtual portal manually according to your business needs:

The Manage Search portlet requires that you assign the following additional role and access rights on it to the virtual portal administrators so that they can use the full functionality of the portlet: Editor@Virtual Resource PSE_SOURCES. To change the content of virtual portals, you can do this by one of the following ways:

If you use the configuration task create-virtual-portal to create a virtual portal, the new virtual portal that you create is empty. You need to create the content for the virtual portal. For example, you can do this by using the XML configuration interface. For more information about the XML configuration interface and how to use it refer to The XML configuration interface.

 

User friendly URL mappings for virtual portals

When you create a virtual portal, you specify the friendly URL. This URL mapping points to the content root of the virtual portal.

Internally, URL mapping corresponds to a unique name...

wps.vp.internal_ID_of_the_virtual_portal

used to identify the virtual portal unambiguously. The URL mapping is also used by:

You can also specify additional URL mappings for a virtual portal, both for the content root or for other content of the virtual portal, for example, a page in the navigation of the virtual portal.

All URL mappings use the same context root and servlet name in the URL. This applies to both the initial URL mapping of a virtual portal and any additional URL mappings that you might create for it.

There is a 1:1 relation between a virtual portal and its initial URL Mapping.

Each mapped URL points to the root content node of one virtual portal. You cannot use the same URL Mapping for two different virtual portals.

You must not delete or modify the initial URL Mapping for a virtual portal or modify its unique name. Deleting this URL Mapping or modifying its unique name makes the virtual portal unusable. This is independent of whether you use the administration portlets URL Mapping or Custom Unique Names or the XML configuration interface to make the change.

If you use an external security manager, such as Tivoli Access Manager, you can restrict the usage of virtual portals by setting security proxy URL filtering rules to block all URLs by default and explicitly enable the defined URL Mappings only.

A URL mapping that is defined for a resource in a particular virtual portal must use the same URL context as the friendly URL context for that virtual portal itself. For example, in a virtual portal that uses the friendly URL mapping...

wps/portal/vp1

...all URL mappings for portal resources must start with...

wps/portal/vp1

...for example...

wps/portal/vp1/url1
wps/portal/vp1/url2

Within this virtual portal a URL mapping such as...

wps/portal/url1

...is not valid, as the portion vp1 of the URL Context is missing.

There are some strings which you cannot use as URL mappings for virtual portals, for example vp. These are strings that are reserved names and correspond with URL codec names. They are listed in the following:

  • cxml
  • cxml_1
  • cxml_2
  • kcxml
  • cxmld
  • wml

  • vp
  • base64xml
  • delta
  • c0
  • c0_1
  • c0_2

  • c1
  • c2
  • c3
  • d0
  • dl2

 

Individual themes and skins for each virtual portal

If you expose multiple virtual portals on a single portal installation, you can give each virtual portal its own look and feel for the user experience. When you create virtual portals, the portal creates parallel root content nodes for each virtual portal. You can apply separate themes and skins for each content root and its child pages without impacting the representation of other content in the parallel trees for the other virtual portals. Each virtual portal will look like its own portal to its users. Users will not be aware that there are two or more different content nodes on the same physical portal installation.

You can apply the specific look and feel of each virtual portal to both the (unauthenticated) Welcome page and the authenticated pages of the virtual portal. This means that each virtual portal can have its own look and feel even before the user logs in to the portal. Users can switch between the unauthenticated pages of different virtual portals by simply entering the different URL to get to the other portal. You can also provide specific login, and self-enrollment pages for each virtual portal. Once users log out, they are redirected to the specific unauthenticated page of the virtual portal that they had accessed.

 

Alternative concepts for virtual portals on WebSphere Portal

Besides virtual portals, another possible configuration may be an alternative for you, depending on your business needs. This setup is referred to as true portals. This setup allows the re-use of a single hardware, with multiple complete portal installations, that is, one dedicated software profile for each portal. Each portal installation requires its own complete WAS installation. These are the main advantages of true portals:

To implement this solution, be aware of the following limitations:

 

Parent topic

Multiple virtual portals

 

Related concepts

Use WSRP services
The XML configuration interface

 

Related information

Administering virtual portals
Configure additional security features