Plan for virtual portals

 

+
Search Tips   |   Advanced Search

 

  1. Overview
  2. Separate and share resources
  3. Portal resources that are scoped
  4. Portal resources that we can scope using Portal Access Control
  5. Portal resources that cannot be scoped
  6. Scoping portlets and portlet applications
  7. Special case: Scoping unique names
  8. Manage the user population
  9. Prepare the user populations
  10. Configure a common user population all virtual portals
  11. Configure separate user populations for the individual virtual portals
  12. Administration
  13. Portal Access Control with virtual portals
  14. The master administrator
  15. Subadministrators of a virtual portal and their access roles and rights
  16. End users of a virtual portal and their access roles and rights
  17. Content of a virtual portal
  18. User friendly URL mappings for virtual portals
  19. Individual themes and skins for each virtual portal
  20. Alternative concepts for virtual portals on WebSphere Portal

 

Overview

Virtual Portals are virtual entities. Logical portals within an existing physical portal.

Characteristics...

  • Distinct URLs
  • Unique pages and user realms
  • Unique set of public pages, logins, themes, and skins
  • Portal resources can be either shared or assigned separately

Virtual Portal administrators

  • Delegated model
  • Given control over pages and virtual portal specific resources

 

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:

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, we can customize such resources for each virtual portal independently.

Example: The resource RESOURCEA is scoped for the virtual portals...

VP_1
VP_2
VP_3

...as...

RESOURCEA_VP_1
RESOURCEA_VP_2
RESOURCEA_VP_3

Customizing RESOURCEA_VP_1 does not affect RESOURCEA_VP_2 and RESOURCEA_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. We can scope some resources by using...

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 that are scoped for virtual portals

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

  • Portal pages
  • Portlet instances
  • Portal Search Engine content sources

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 subadministrator can use PAC to grant individual users of that virtual portal specific access rights to the scoped portal resources. This works just like under a single portal installation.

  • An administrator can give access rights 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 rights 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 rights when they access the specific virtual portal under which they have the access rights on the scoped resources. The same users cannot access the resources when logging in to a different virtual portal.

 

Portal resources that we can scope for virtual portals by using PAC

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 scope such portal resources for the virtual portals yourself. You do this by specifying in which virtual portal you want these resources to be visible and accessible. To do this, you use PAC and the access rights portlets to set up the appropriate access rights.

We can scope the following portal resources by using PAC to give users of an individual virtual portal access right to the resources:

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

 

Portal resources that cannot be scoped for virtual portals

There are some types of portal resources that cannot be scoped to a particular virtual portal. These are not scoped internally by the portal, and we cannot scope them yourself by using PAC. The following list shows portal resources that we cannot scope for virtual portals:

  • Themes and skins.

    If you do not want subadministrators to be able to manage themes and skins, restrict their access rights on them.

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

  • Composite applications and templates.

    There is one common application and template catalog per installation. Users see the applications and templates to which they have access, regardless of virtual portal assignments.

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

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.

 

Scoping portlets and portlet applications

  • Scoping portlet applications

    Portlet applications are not scoped for virtual portals. Therefore, the configuration settings set for a portlet application by 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.

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

    • Manage Portlets portlet
    • Configure mode of the portlet.

    If we 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 set for a portlet by using the...

    • Personalize
    • 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:

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

 

Manage the user population for virtual portals

There are two basic options for the management of user populations...

  • Using the Member Manager Custom User Registry.

    Use the Member Manager Custom User Registry to set up both types of configuration:

    • Configure separate user populations for each virtual portal.

      With this configuration we can define an individual user population for each virtual portal.

    • Use a common user population with Member Manager for all virtual portals.

      All users of the user population can access all virtual portals, unless their access rights are explicitly restricted by PAC portlets.

  • Using the LDAP or database user registry of WebSphere Application Server.

    If a single common user repository is sufficient for all virtual portals within the installation, we can continue to use an LDAP or database user registry in the virtual portal setup. This is the simpler one of the two options. This option does not use Member Manager.

    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.

    To achieve access restrictions for specific virtual portals, we can use the PAC portlets. You define user groups and assign to them the access rights to the resources of each virtual portal.

For WebSphere Portal Version 6.0 installations, the Member Manager custom user registry is the advanced option. It offers you more flexibility for the user management of virtual portals. By using the Member Manager we can limit the usage of a particular virtual portal to a specific user population. This is achieved by introducing the concept of realms.

The following sections give overview information of how to use Member Manager and realms in the context of virtual portals. For a wider overview of portal security refer to...

A virtual portal can only be accessed by members of its associated user population. By using PAC we can assign and restrict access rights within the user population of a virtual portal to the resources of that virtual portal.

PAC cannot overwrite the predefined assignment of a particular user population to their virtual portal. Consequently, we cannot use PAC to assign access rights that cross the separation between virtual portals.

For example, we cannot use the PAC of a virtual portal VP1 to give a user User1 of that portal access to resources of another virtual portal VP2. The following conditions apply:

  • A realm contains the entire user population of one virtual portal.

  • Each virtual portal can have its own realm of users associated, but it is also possible that multiple virtual portals can share their user population by using the same realm in parallel.

  • To log in to a particular virtual portal, a user must be a member of the realm that is associated with that virtual portal.

 

Prepare the user populations

If you plan to use realms for the virtual portals, configure Member Manager and the realms prior to creating the virtual portals.

Each realm must specify the Member Manager nodes that belong to the user population represented by this realm.

In addition to the realms created to define the user populations of the individual virtual portals, create a super realm that spans all other realms and contains all the users of those other realms.

You configure the Member Manager Custom User Registry after the portal installation when you enable the Custom User Registry. WebSphere Portal does not provide a configuration task for doing this.

You must configure the realms manually in the configuration file wmmur.xml.

  • For standard portal installations the file is located in...

    portal_server_root/wmm

  • For portal cluster installations the file is located on the Deployment Manager machine.

    To edit wmmur.xml...

    1. Use the configuration task...

      check-out-wmm-cfg-files-from-dmgr

      ...to download the current configuration files from the Deployment Manager to the local portal installation.

      After the download the file can be found in...

      portal_server_root/wmm

    2. Edit the file wmmur.xml and make the updates required by the portal configuration.

    3. After you have modified the file, upload to the Deployment Manager by using...

      check-in-wmm-cfg-files-to-dmgr

After you configure or reconfigure Member Manager, restart WebSphere Application Server.

The following sections give an overview of example configurations of Member Manager for virtual portals.

 

Configure a common user population for all virtual portals

In a simple setup we can use Member Manager 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 Version 6.0 still supports the WAS LDAP custom user registry that previous versions of WebSphere Portal used. We 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

If you want to have the users of the virtual portals separated, you have to apply the more advanced setup by using Member Manager and configuring separate realms for the 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 the portal installation.

This separation of user populations between virtual portals works only with Member Manager. WebSphere Portal supports separate realms and user repositories for virtual portals only when you use the Member Manager custom user registry.

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

  • We 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. We can separate the user population of each virtual portal by assigning different LDAP suffixes to the different realms The LDAP suffixes are called WMM nodes.

  • A realm can aggregate one or more nodes in a user registry.

  • A realm can combine multiple suffixes 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. However, if you search, modify, or delete users or groups, the global Member Manager configuration from the file wmm.xml is used instead of the super realm.

  • When you use Member Manager, 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 Member Manager.

  • The individual user IDs must be unique across all realms

  • 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 Member Manager 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.

  • 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, users can work in all the virtual portals which are associated with these realms.

For example, we can set up the following configurations:

  • We can configure one LDAP suffix with all administrative users, for example...

    dc=administrators,dc=ibm,dc=com

    ...and a separate LDAP suffix with the end users, for example...

    dc=users,dc=ibm,dc=com

  • We can configure separate LDAP suffixes that contain different user populations, for example...

    dc=bank1,dc=com

    ...for...

    Bank_1

    ...and...

    dc=bank2,dc=com

    ...for Bank_2.

The PAC 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 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 you 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

 

Plan considerations for administering virtual portals

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

 

PAC with virtual portals

Some portal resources, such as portlet applications, can be scoped to specific virtual portals by limiting their accessibility using PAC.

A super administrator can...

The inheritance concept of PAC allows this setup.

  • Subadministrators of virtual portals implicitly have the administrative access rights for all the child pages of their respective root content nodes, and thereby of the content of their virtual portals. The subadministrator of a virtual portal cannot assign any access right on resources that are scoped for other virtual portals.

  • Depending on the access rights to users and groups that the master administrator gives the subadministrators, they can grant access to users who belong to the user population of their virtual portals. The subadministrator of a virtual portal cannot assign any access rights to users or groups of other virtual portals.

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

 

The master administrator

A key role for the administration of virtual portals is the master administrator. This user ID is created during the initial installation of WebSphere Portal with the role administrator on the portal ( admin@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. We can 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 PAC or can define realms in the Member Manager configuration files. For more detail about this refer to...

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 we 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 PAC.

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:

  • By the master administrator of the portal installation. For example, this can be by done using the XML configuration interface.

  • By the subadministrators or other users of the virtual portal. They can do this only by using the Manage Pages portlet.

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

  • Using the Virtual Portal Manager portlet

  • Using the XML configuration interface to perform tasks related to one of the virtual portals

  • Installing portlets, themes, and skins.

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

By using WSRP we 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 detail about PAC refer to Configuring security.

For more detail about virtual portal security refer to PAC with virtual portals.

 

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 that you 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.

We can assign additional access rights on portal resources to the subadministrators. For example...

To assign additional access rights to the subadministrators after creating a virtual portal, use the master administrator user ID of the portal installation and modify those access rights for them manually in PAC. To do this, we can use...

If you do this in the initial portal installation, we can change the access rights for the subadministrators on the virtual portal as a whole.

If you do this in the virtual portal itself, we can change the access rights for the subadministrators on the individual resources of the virtual portal.

 

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

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

  • The All Authenticated Users group is common across all virtual portals that share the same realm. When you create virtual portals, this group is given the Privileged User role on resources of all those virtual portals, independent of the role assignments that its users have on the initial portal installation.

    Restrict role assignments and thereby access rights for the All Authenticated Users group, and assign access to user groups or users as required.

  • The All Authenticated Users group is valid over all virtual portals that share the same realm. This means that users who are in a realm that belongs to more than one virtual portal, these users have the assigned roles on all virtual portals to which they have access by membership to that realm.

To configure the scope of access rights for users before creating a virtual portal, configure realms and user groups accordingly.

To change the access rights of users of a virtual portal after creating a virtual portal, use the PAC portlets in that virtual portal. We can have the subadministrators of the virtual portal perform this task.

 

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.

By default, the initial content of a new virtual portal includes the pages and portlets listed in the following. The list also includes in parentheses the unique names that are used for the pages and portlets in WebSphere Portal Version 6.0.

Content (ibm.portal.Content)

  • Home (ibm.portal.Home).

  • Welcome (ibm.portal.WebSphere Portal.Welcome)

    • Welcome (wps.p.Welcome)

  • My Page

  • Page Customizer (ibm.portal.Page Customizer)

  • Page Properties (ibm.portal.Page Properties)

  • Organize Favorites (wps.p.Favorites)

  • Login (wps.Login)

    • Login (wps.p.login)

  • Search (wps.p.Search Center)

  • Enrollment/Selfcare (wps.p.Selfcare)

  • Documents (wps.Documents)

  • Administration (ibm.portal.Administration)

    Manage Pages wps.p.Manage Pages
    Users and Groups wps.p.Manage Users and Groups
    Resource Permissions wps.p.Resource View
    User and Group Permissions wps.p.User Group Permissions
    URL Mapping wps.p.Url Mapping
    Custom Unique names wps.p.Unique Names
    Manage Search wps.p.Manage Search Admin
    Manage Document Libraries wps.p.MDL
    Enable tracing wps.p.Enable Tracing
    Palette wps.p.Content Palette
    Personalization Picker ibm.portal.Personalization.Picker.portlet
    Applications wps.p.App Catalog
    Edit Layout wps.p.Content Layout
    Members wps.p.App Membership
    Roles wps.p.App Roles
    Properties wps.p.App Properties
    Parameters wps.p.Template Parameters
    Application Layout wps.p.Application Layout
    Application Template Library wps.p.Template Library
    Portlet Wiring Tool wps.p.Wiring
    Appearance portlet wps.p.Appearance
    Page Locks wps.p.Permissions
    Page Properties wps.p.Properties
    Information Portlet wps.p.Information
    Anonymous Information wps.p.Information.Anonymous. This portlet is hidden.
    Policy Editor wps.p.PolicyEditor
    Resource Policies wps.p.PolicyExplorer

By default 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. We 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:

  • Administrator to the content root (Administrator@content root) of the virtual portal

  • Editor to portlet instances (Editor@portlet entities) that are created for the new virtual portal.

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

  • To change the roles and access rights for subadministrators on the portlets globally and before you create a virtual portal, configure the Virtual Portal Manager portlet accordingly.

  • To change the roles and access rights specifically and after creating a virtual portal, use the PAC portlets. If you do this in the initial portal installation, we can change the access rights on the virtual portal as a whole. If you do this in the virtual portal itself, we can change the access rights on the individual resources of the virtual portal.

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, we can do this by one of the following ways:

  • To change the content globally and before creating a virtual portal, advanced administrators can re-configure the XML script that specifies the initial content for virtual portals.

    When modifying or replacing this XML script, plan well ahead and apply special care. We can add or remove some content in order to enhance or reduce the functionality of a virtual portal to a certain extent.

    The following portal resources are mandatory content of a virtual portal and must be included in a customized XML initialization script for virtual portals:

    • Content Root (wps.content.root)
    • Login (wps.Login)
    • Administration (ibm.portal.Administration).

    Depending on the functionality that you want to make available, more content is required. For example, in order to allow templating. include Application Root (wps.application.root) and Templates (ibm.portal.Templates).

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

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, we can do this by using the XML configuration interface.

 

User friendly URL mappings for virtual portals

We can provide user friendly URLs for the users to access their virtual portals. For example...

http://www.ibm.com:10038/wps/portal/MyDept

The URL mapping specified is assigned to the virtual portal during initialization and points to the content root of the virtual portal.

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. We cannot use the same URL mapping for two different virtual portals.

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 we cannot use as URL mappings for virtual portals, for example vp. These are strings that are reserved names and correspond with URL codec names...

  • cxml
  • cxml_1
  • cxml_2

  • kcxml
  • cxmld
  • wml

  • vp
  • base64xml
  • delta

  • c0
  • c0_1
  • c0_2

  • c1
  • c2
  • c3

  • d0
  • dl2

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. The XML configuration interface and the Portal Scripting Interface also use this URL mapping to identify the virtual portal.

Therefore not delete this initial URL mapping for a virtual portal. Deleting this URL mapping makes the virtual portal unusable.

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

If you use an external security manager, such as IBM Tivoli Access Manager for e-business, we 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.

 

Individual themes and skins for each virtual portal

If you expose multiple virtual portals on a single portal installation, we 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. We 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.

We 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. We can also provide specific login, and self-enrolment 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 the business needs. This setup is referred to as true portals. This setup allows the re-use of a single hardware, with multiple full portal installations, that is, one dedicated software profile for each portal. Each portal installation requires its own full WebSphere Application Server 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:

  • We 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.

  • We cannot share applications or data between true portals.

 

Related information

  1. About multiple virtual portals
  2. Usage scenarios for virtual portals
  3. Administer virtual portals
  4. Virtual portals reference
  5. Portal configuration
  6. The XML configuration interface
  7. Administering

 

Parent topic:

Multiple virtual portals