Plan for virtual portals


  1. Overview
  2. Separate and share resources between virtual portals
  3. Scoped for virtual portals
  4. Separate for virtual portals
  5. Cannot be separated
  6. Separate portlets and portlet applications
  7. Scope portlet instances
  8. Scope unique names
  9. Common user population
  10. Separate user populations
  11. Manage the user population for virtual portals
  12. Prepare the user populations for virtual portals
  13. Administer virtual portals
  14. Portal Access Control with virtual portals
  15. Administrator
  16. Sub-administrators
    1. Determine user group after virtual portal creation
    2. Change the default Editor access right
  17. Users of a virtual portal and their access roles and rights
  18. Content of a virtual portal
  19. User experience
  20. Human readable URL mappings
  21. Individual themes and skins for each virtual portal
  22. Alternative concepts for virtual portals on WebSphere Portal


Overview

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

The portal administrator needs to be assigned the monitor role in the WAS console. If the portal administrative user is not the same as the WAS administrative user, then follow these steps to assign the portal administrator the monitor role.

  1. Login to the WebSphere Administrative Server console and click...

      Users and Groups | Administrative user roles | administrator_user

    If the portal administrator user is not displayed, click Add and enter the administrator id in the User field.

  2. Select Monitor in the roles text box.

  3. Apply changes and save.


Separate and share resources between virtual portals

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

Scope works for some portal resources, but not for others:

The differences in scoping portal resources are described in the following sections.


Portal resources that are scoped for virtual portals

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

Scope of these resources is managed by internal portal mechanisms. 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 the following portal resources by using Portal Access Control to give users of an individual virtual portal access right to the resources:

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

Resources not scoped to a particular virtual portal...


Separate portlets and portlet applications

Portlet applications are not scoped for virtual portals. Configuration settings set for a portlet application using the Manage Applications portlet apply to that portlet application in all virtual portals. For different configurations, create a copy of the portlet application, and configure the copied portlet application as required.

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.

The following settings for a portlet apply to that portlet in all virtual portals:

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


Scope 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: Scope 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 virtual portals:

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:


Prepare the user populations for virtual portals

If you plan to use realms for virtual portals, you need to configure VMM and the realms before creating virtual portals. Each realm must specify the repository nodes (base entries) that belong to the user population represented by this realm.

In addition to the realms that you create 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 User Registry provider. By default only the super realm, or default realm, is configured. After you have configured the portal instance against user backend repositories you can use tasks provided by the portal to configure the realms that the VMM provides. For the task that describes how to add a realm and modify the base entries or nodes inside that realm refer to the topics about adding realm support.

While the realm for the base portal installation can be re-configured to a non-default realm, do not perform this procedure if you have Web Content Manager, as Web Content Manager is not scoped to virtual portals.


Configure a common user population for all virtual portals

In a simple setup you can 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 Lightweight Directory Access Protocol (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 virtual portals separated, apply Federated Repositories and configure a separate realm for each virtual portal. 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.

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

You can aggregate users and groups from one user registry in one realm, and thereby expose them as one coherent user population to the portal installation. You can separate the user population of each virtual portal by assigning different LDAP suffixes to the different realms. The LDAP suffixes are called base entries.

A realm can aggregate one or more base entries in a user registry.

A realm can combine multiple base entries of one user repository. A suffix of a user repository can belong to one or more realms. Consequently, the LDAP suffixes of the individual users must match the suffixes of the groups to which they belong.

A virtual portal is associated with one realm. Each virtual portal uses exactly one realm, but a realm can be used by multiple virtual portals.

A virtual portal can also be associated with no realm. If no realm is assigned for a virtual portal, the user population that was defined for the super realm can log on to the virtual portal.

When you use Federated Repositories, the initial portal installation has no realm associated by default. The user population of the initial portal installation spans the entire user registry that you configured in the VMM.

The individual user IDs must be unique across all realms.

In order to log in to a virtual portal, the virtual portal administrator and all users must be a member of the realm for that virtual portal. To allow a user access to more than one virtual portal, that user (and thereby the VMM node to which the user belongs in the hierarchy of the user directory) must be a member of all the realms associated with these virtual portals. For example, this applies to a super administrator who is responsible for all virtual portals within an entire Portal installation.

In order to administer the virtual portals, the master administrator must be a member of the realms of these virtual portals.

User populations of realms can overlap. In other words, users can be members of multiple realms. If realms overlap, that is if some users are in different realms for different virtual portals, then these users can work in all the virtual portals which are associated with these realms.

The administrator unique ID for the Java Content Repository (JCR) must be an distinguished name (DN) for a super administrator. You specify the administrator unique ID as the value for jcr.admin.uniqueName in:

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 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 AdministrationAccessResource PermissionsSelect Resource Type Assign Access for a resourceEdit Role, under the first column Members in the Role.


Granting 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:


Plan considerations for administering virtual portals

The following sections describe the planning considerations required for virtual portals with regards to the following:

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


Portal Access Control with virtual portals

We can scope portal resources for the virtual portal using portal administration and Portal Access Control.

For example, though Application resources are, by default, available to all virtual portals, we can scope these resources to specific virtual portals by limiting their accessibility by realm. Resources scoped to a realm are only available in virtual portals that use the realm.

A master administrator can delegate subsets of administration privileges to other administrative users:

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

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 the master administrator of both the initial portal installation and all virtual portals that are created.

Virtual portal tasks can be performed using either:

To separate the user populations of the individual virtual portals:

When creating the virtual portal, a default set of roles and access rights is assigned via a specified "User Group". Members of this user group are sub-administrators of the virtual portal. These assignments can be modified using the Resource Permissions portlet.

Virtual portal content can be further enhanced...

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

Do not grant the sub-administrators 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 Java Virtual Machine (JVM). Therefore it is important to restrict the administration privileges of the virtual portal sub-administrators 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 webservices for remote portlets (WSRP). By using WSRP you can provide portlets on a remote machine and then have the virtual portals consume those portlets so that users can access them remotely. For more information about using WSRP with the portal refer to Use WSRP services.

For more detail about Portal Access Control refer to Controlling access. For more detail about virtual portal security refer to Portal Access Control with virtual portals.


Sub-administrators access roles and rights

When you create the virtual portal with the Virtual Portal Manager portlet, a user group is specified to serve as the sub-administrator group, responsible for the administration 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 specified group:

As the sub-administrators 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.


Determine user group after virtual portal creation

To find the user group after vp creation, export the content-node wps.content.root using xmlaccess ExportRelease or the Manage Pages portlet. For example:


Change the default Editor access right

You can preconfigure subadmin access rights within the Virtual Portal Manager portlet, for example, by adding the add the following access rights to:

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


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 xmlaccess.sh 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 sub-administrators of the virtual portal:

You can modify the roles and access rights for the sub-administrators of a virtual portal manually according to 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:

  • To change the content specifically and after creating a virtual portal, use either of the following portal tools:

    • Use the Manage Pages portlet of the virtual portal. You can have the sub-administrator of the virtual portal do this.

    • Use xmlaccess.sh to import content into the virtual portal. This can only be done from the initial portal installation.

    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 xmlaccess.sh.


    Shaping the user experience

    The following sections describe how you can shape the user experience that users have with virtual portals.


    Human readable URL mappings for virtual portals

    You can provide human readable URLs for users to access their virtual portals. For example, you can give each virtual portal a human readable URL, such as http://www.ibm.com:10040/wps/portal/tivoli. You can pass the human readable URL of a virtual portal to its users. They can then use it to access their virtual portal.

    When you create a virtual portal, you specify the human readable URL as required by business environment. The URL mapping that you specify is assigned to the virtual portal during its initialization. The URL mapping points to the content root of the virtual portal.

    Internally, this URL mapping corresponds to a unique name wps.vp.internal_ID_of_the_virtual_portal. The portal installation uses this unique name to identify and access the virtual portal unambiguously. xmlaccess.sh and the Portal Scripting Interface also use this URL mapping to identify the virtual portal.

    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.
    Notes:

    1. 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.

    2. 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 administration portlets URL Mapping or Custom Unique Names or the xmlaccess.sh to make the change.

    3. If you use an external security manager, such as TivoliAccess Manager (TAM), you can restrict the usage of virtual portals by means of the URL Mappings. To do this, you base the URL filtering rules of a security proxy on the URL Mappings that you defined. If you do this, block all URLs by default and explicitly enable the defined URL Mappings only.

    4. A URL mapping that is defined for a resource in a particular virtual portal must use the same URL context as the human readable URL context for that virtual portal itself. Example: In a virtual portal that uses the human readable URL mapping wps/portal/vp_1, all URL mappings for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal a URL mapping such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.

    5. 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 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:

    • The strong isolation of the configuration data due to separate configuration databases
    • The full isolation of applications, due to a separate JVM for each true portal. This allows better quality of service.

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

    • You can run only a limited number of true portals on a single hardware machine. This is due to the memory volume required by the JVM.

    • You cannot share applications or data between true portals.


    Parent

    Multiple virtual portals
    Usage scenarios for virtual portals
    Use WSRP services
    Controlling access
    xmlaccess.sh
    Virtual portals reference


    Administer virtual portals

     


    +

    Search Tips   |   Advanced Search