+

Search Tips   |   Advanced Search

Separate and share resources between virtual portals

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

Scoping of resources works as follows:

  • A portal resource that is scoped for virtual portals exists individually for each virtual portal. It has an identification unique within the entire portal installation. The resource is available only in one particular virtual portal. Consequently, we can customize such resources for each virtual portal independently. Example: The resource resource_A is scoped for the virtual portals VP_1, VP_2, and VP_3 as resource_A_VP_1, resource_A_VP_2, and resource_A_VP_3. Customizing resource_A_VP_1 does not affect resource_A_VP_2 or 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.

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

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

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

    • We can scope some resources using portal administration and Portal Access Control.
    • There are some portal resources that cannot be scoped at all.

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


Portal resources scoped for virtual portals

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

  • Portal pages
  • Portlet instances
  • Portal Search Engine search services and search collections. This includes the search content sources.
  • WCM web content libraries.

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

  • Within each virtual portal you or a sub-administrator can use Portal Access Control to grant individual users of that virtual portal specific access permissions to the scoped portal resources. This works just like under a single portal installation.

  • An administrator can give access permissions to users who are members of the user population of a virtual portal only on the scoped resources of that same virtual portal. This implies that, vice versa, we can give access permissions on the resources of a virtual portal only to those users who are members of the user population of that virtual portal.

  • Users can only use these access permissions when they access the specific virtual portal under which they have the access permissions on the scoped resources. The same users cannot access the resources when logging in to a different virtual portal.

WCM libraries are scoped to virtual portals if Managed Pages are enabled as by the default WebSphere Portal installation. To make WCM libraries available between the virtual portals, we can do so by disabling Managed Pages and restarting the portal. WCM libraries of the base portal are then also available to the virtual portals.


Portal resources we can separate for virtual portals 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 we can separate such portal resources for the virtual portals. To do this, use Portal Access Control and the access permissions portlets to set up the appropriate access permissions for users on the resources of each virtual portal as required.

We can separate the following portal resources using Portal Access Control to give users of an individual virtual portal access permission to the resources:

  • Portlets
  • Portlet applications
  • Web modules
  • URL mapping contexts
  • Users and groups

We can separate these resources for individual virtual portals using Portal Access Control.


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 we cannot separate them using Portal Access Control.

    Themes and skins

    If we do not want sub-administrators to be able to manage themes and skins, restrict access permissions.

    Vault segments and vault slots

    To avoid security problems, use private credentials only. They can be used by only one specific user.

    Supported clients and markups

    The settings for these are configured in the corresponding portlets; therefore they apply to the entire portal installation.

    Policies

    Policy resources are not scoped to virtual portals. Users see the policy resources to which they have access, regardless of the virtual portal assignments.

    Personalization

    Personalization is not aware of virtual portals. A document library available in the initial portal installation is also available in each virtual portal, if Personalization is available in that virtual portal and is configured to use that document library. Searching for a document in a document library will produce a document reference (URL) that is different in each virtual portal, but points to the same document in the document library. To provide separation of content within virtual portals, use separate document libraries for each virtual portal. To provide content collaboration between virtual portals, use the same document libraries between virtual portals.

Example: Themes and skins can be accessed by all sub-administrators who have the access permission to apply themes and skins to the pages they can administer, regardless of which virtual portal the sub-administrators are responsible for.


Separating portlets, portlet applications, and portlet instances

Portlet applications are not scoped for virtual portals. Therefore, the configuration settings set for a portlet application using the Manage Applications portlet apply to that portlet application in all virtual portals. If we 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.

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:

  • The configuration settings set for a portlet using the Manage Portlets portlet

  • The configuration settings set for a portlet using the Configure mode of the portlet.

Portlet instances are scoped to the virtual portals. If we need different configurations for a portlet between virtual portals, create a copy of the portlet, and configure the copied portlet as required. The configuration settings set for a portlet 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 applied 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:

  • Unique names for scoped portal resources are themselves also scoped.

  • Unique names for resources that are not scoped are themselves not scoped.

Example for a scoped unique name: Each virtual portal has its own separate login page. Therefore we 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. We can assign a unique name to the portlet application. We can reference that portlet application by that unique name throughout the portal installation with all virtual portals.


Parent Plan for virtual portals


Related information


Technotes for virtual portals