Hints and tips for working with virtual portals

View information about configuring virtual portals, hints and tips, and known limitations in WebSphere Portal v8.5:

• Do not grant the subadministrators of virtual portals the access permissions to run any installation-related tasks, such as installation of portlets or themes. The isolation between the different virtual portals as provided by WebSphere Portal v8.5 is limited to some extent. All virtual portals share a common Java virtual machine (JVM). Therefore, it is important to restrict the administration privileges of the virtual portal subadministrators and prevent them from installing their own code artifacts, such as themes or portlets. Unstable or malicious code that is introduced on one virtual portal can destabilize the entire portal installation and all other virtual portals. A flexible way to introduce virtual portal specific portlets without impacting any other virtual portals is to use Web Services for Remote Portlets (WSRP). For more information about WSRP, refer to Use WSRP services.

• Not all resources can be scoped to individual virtual portals. For example, all themes and skins are available to all virtual portals without restrictions. Credential vault, portlet services, and portal services are also common for an entire portal installation. They cannot be scoped to an individual virtual portal.

• The settings defined in the portal property files apply for the entire portal installation. We cannot specify separate settings for individual virtual portals.

• To use the single signon feature provided by WebSphere Application Server, use the same common domain suffix for all virtual portals.

• Portal search, personalization, and templates, are not aware of virtual portals.

• There are no virtual portal specific enhancements to the published portal commands and application programming interfaces.

• A URL mapping 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.

• The administration portlet Virtual Portal Manager cannot delete all resources associated with a virtual portal. For example, it does not delete extra URL mappings that administrators created for the virtual portal. Use xmlaccess.sh to delete the URL mappings.

• All virtual portals on a portal installation share a common logging and tracing.

• When we reinitialize a virtual portal using the Virtual Portal Manager portlet, this applies the XML script for the default virtual portal content (or the custom script) again and re-creates the default content of the virtual portal. Resources that you removed from the default content are re-created. Resources that you added to the default content remain in the virtual portal.

• Run the wp-create-realm task to create realms for the virtual portal. See the topics about Realm support and about adding realm support file for the operating system.

• 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 we are 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 the local virtual portal are displayed as usual, but role members who belong to different realms are displayed in a different manner:

  • Role members for shared resources who belong to the realm of the virtual portal under which we are currently working are listed by their actual names under which they were created.

  • Role members for shared resources that do not belong to the realm of the current portal are listed by their portal object IDs. For example, a role member from a different realm might be represented as 8_0_B.

  You find the list of role members under Administration > Access > Resource Permissions > Select Resource Type > Assigning Access for a resource > Edit Role, under the first column Members in the Role.

• We cannot create custom URLs in one virtual portal that address portal resource in another virtual portal. The reason is that both object IDs and unique names relate to resources of the local virtual portal.

Parent Virtual portals reference

Related concepts:

WSRP services
Realm support

Related information

Technotes for virtual portals