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:

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

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

  • VP_1
  • VP_2
  • VP_3

  .as...

  • resource_A_VP_1
  • resource_A_VP_2
  • resource_A_VP_3

  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.

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

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

  • You can scope some resources by 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.

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:

• Portal pages
• Portlet instances
• Portal Search Engine search services and search collections. This includes the search content sources.
• Composite applications and templates.

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:

• Within each virtual portal you or a sub-administrator can use Portal Access Control 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, you 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 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:

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

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

• Themes and skins

  To prevent access by sub-administrators, restrict access rights.

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

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:

• Manage Portlets portlet
• "Configure" mode of the portlet

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:

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

• Use Virtual Member Manager (Federated Repository), integrated with WAS, to either...

  • Configure separate user populations for each of virtual portals using realms.

  • Use a common user population with the VMM for all virtual portals. All users of that user population can access all virtual portals, unless their access rights are explicitly restricted by portal access control settings.

• Use a single LDAP or database. Simpler of the options. The entire portal installation and all virtual portals share a common user population, which is defined in a single user repository.

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:

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

• In order to be able 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 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:

was_profile_root/PortalServer/jcr/lib/com/ibm/icm.properties

For example, you can set up the following configurations:

You can configure one LDAP suffix with all administrative users, for example dc=administrators,dc=ibm,dc=com and a separate LDAP suffix with the users, for example...
dc=users,dc=ibm,dc=com

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

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

• You can assign virtual portal administrators access to the JCR content root node using the Set access on root button in the Web Content Library view of the Administration portlet. See Set root access for all web content libraries wp7 for further information.

  • Assign virtual portal administrators administrator access to the JCR content root node to enable them to create new libraries and view, edit and delete all existing libraries.

  • Assign virtual portal administrators contributor access to the JCR content root node to enable them to create new libraries and view, edit and delete libraries they have created.

• You can also assign virtual portal administrators access to libraries they have not created by editing the access settings of individual libraries.

Plan considerations for administering virtual portals

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

• Portal Access Control with virtual portals
• The master administrator
• Sub-administrators of a virtual portal and their access roles and rights
• Users of a virtual portal and their access roles and rights
• Content of a virtual portal

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

• If during the portal installation you selected the option to install a portal that includes the administration portlets, you can use the Virtual Portal Manager portlet to create virtual portals.

• If you selected the option to install a full portal, you can use the Virtual Portal Manager portlet to create virtual portals. In this case you have the choice between different sets of content for virtual portal. For details about this refer to Preconfiguring the default content for virtual portals.

• If you selected the option to install an empty portal without content, the portal does not include the Virtual Portal Manager portlet. In this case you have the following options for creating virtual portals:

  • Deploy the Virtual Portal Manager portlet and use it to create virtual portals. In this case preconfigure virtual portal and its content. For details about how to do this refer to Preconfiguring virtual portals and its subtopics.

  • Use the appropriate configuration task to create virtual portals. For details about this refer to Create a virtual portal.
    If you use the configuration task create-virtual-portal to create a virtual portal, the virtual portal is created without content. In this case you can use xmlaccess.sh to fill the virtual portal with content.

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:

• Use delegated administration to set up individual partitions in the portal for the virtual portals

• Define separate sub-administrator users who administer the individual virtual portals and give each of the sub-administrators the access rights for their virtual portals.

• Define separate user populations who can access the individual virtual portals.

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:

• By inheritance, sub-administrators 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 sub-administrator 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 sub-administrators, they can grant access to users who belong to the user population of their virtual portals. The sub-administrator 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

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

admin@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:

• Virtual Portal Manager portlet
• configuration tasks

To separate the user populations of the individual virtual portals:

• Leverage the User and Group Permissions portlet
• Define realms in the VMM configuration files

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

• By the master administrator of the portal installation.
• By sub-administrators of the virtual portal using the Manage Pages portlet.

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

• Virtual Portal Manager portlet
• xmlaccess.sh
• Install portlets, themes, and skins.

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:

• Administrator role access right on the root label of the virtual portal. You cannot change this access right.

• Administrator role access right on the virtual portal URL context. You cannot change this access right.

• Editor role access right on the administration portlets that are part of the virtual portal. You can change this access right.

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:

<access-control externalized="false" 
                owner="undefined" 
                private="false">

    <role actionset="Administrator" 
          update="set">

      <mapping subjectid="cn=wps.intranet.dev,ou=groups,dc=foo,dc=com" 
               subjecttype="user_group" 
               update="set" /> 

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:

• Perform portal user and group management tasks related to the user population of the virtual portal.

• Grant permissions to users and groups of the virtual portal.

• Manage WSRP, URL mappings, or Portal Search Engine search collections.

• All other access rights that are available by the Portal Access Control.

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:

• If you do this in the initial portal installation, you can change the access rights for the sub-administrators on the virtual portal as a whole.

• If you do this in the virtual portal itself, you can change the access rights for the sub-administrators on the individual resources of the virtual portal.

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 change these default roles and the access rights for the users, you can do this by one of the following ways:

• 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 Portal Access Control portlets in that virtual portal. You can have the sub-administrators 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 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:

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

You can modify the roles and access rights for the sub-administrators of a virtual portal manually according to business needs:

• To change the roles and access rights for sub-administrators on the portlets globally and before you create a virtual portal, configure the Virtual Portal Manager portlet accordingly. For details about how to do this refer to Preconfiguring the sub-administrators for virtual portals.

• To change the roles and access rights specifically and after creating a virtual portal, use the Portal Access Control portlets. If you do this in the initial portal installation, you can change the access rights on the virtual portal as a whole. If you do this in the virtual portal itself, you 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, you can do this by one of the following ways:

• To change the content globally and before creating a virtual portal, advanced master administrators can re-configure the XML script that specifies the initial content for virtual portals. For details about how to do this refer to Preconfiguring the default content for virtual portals.

  When you modify or replace this XML script, plan well ahead and apply special care. You 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:

• 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