Modifying the URL mapping of virtual portal context

It seems that if you change the url mapping of the VirtualPortalContext url then you will run into strange issues such as the createResourceURL() returning wrong URL, our team ran into this issue yesterday so i did little bit of debugging to see what happens.

I started by creating a new Virtual Portal test2, after creating the virtual portal i did create full export of the virtual portal as soon as the virtual portal was created. When i looked at the export i could see that it already had a URL mapping for test2, which is the context of the virtual portal like this

   <url-mapping-context action="update" domain="rel" label="test2" objectid="C_VVILMKG108MAF0IS7PPFSE10S6">
            <access-control externalized="false" owner="uid=wasadmin,o=defaultwimfilebasedrealm" private="false"/>
            <portal-url resourceref="6_000000000000000000000000A0" update="set"/>
        </url-mapping-context>

And this mapping is pointing to the 6_000000000000000000000000A0 node and when i checked the xmlaccess 6_000000000000000000000000A0 is pointing to the wps.content.root page like this

 <content-node action="update" active="true" domain="rel" objectid="6_000000000000000000000000A0" ordinal="0" type="label" uniquename="wps.content.root">
        <supported-markup markup="html" update="set"/>
        <access-control externalized="false" owner="undefined" private="false"/>
</content-node>
<credential-segment action="update" adapter-type="default-customization" domain="cust" name="DefaultUserSegment" objectid="E_CGAH47L008IC40I4BOR2EO00U6" user-mapped="true">
        <description>Default User Segment</description>
</credential-segment>
<credential-segment action="update" adapter-type="default-release" domain="rel" name="DefaultAdminSegment" objectid="E_CGAH47L008IC40I4BOR2EO00U1" user-mapped="false">
        <description>Default Admin Segment</description>
</credential-segment>

Document libraries in virtual portal

A document library that is available in the initial portal installation may also be available in each virtual portal. This depends on personalization being available in that virtual portal and being configured appropriately concerning 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 these discrete references point 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.

Steps for replacing default intial content of VP

If you want you can replace the initial content of the virtual portal that you create using Manage Virtual portal portlet. To replace the default XML script with your own custom XML script, proceed as follows:

1. Place your custom XML script in the following directory:
   was_profile_root/installedApps/cellname/wps.ear/wps.war/virtualportal


2. Open the Manage Portlets portlet by selecting Administration < Portlet Management< Portlets.


3. In the list of portlets, locate the Virtual Portal Manager portlet.


4. Click the Configure Portlet (wrench) icon of the Virtual Portal Manager portlet.


5. Edit the SCRIPT_INIT_VP parameter of the portlet. Replace the value
   InitVirtualPortal.xml with the name of your custom XML script. You might need to
   note the parameter and remove it, and then re-enter the parameter with the name of
   your XML file.


6. Click OK twice to save changes.

Customizing initial content of the virtual portal

Advanced master administrators can customize the default content for virtual portals as required, by modifying or replacing the XML script that specifies the initial content for virtual portals.

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

Sequence of process that executes when you create a new virtual portal

With the information that the administrator enters in Manage Virtual portal when creating the new virtual portal, the portlet triggers a sequence of processes to actually establish the new virtual portal. These processes include the following:

• Creating a new root content node for the virtual portal.


• Creating the new URL mapping to point to the new root content node.


• Assigning the selected theme to the new root content node.


• Granting the specified administrator group the action set for the Administrator role on the new root content node, and thereby, on the new virtual portal.


• Calling the XML configuration interface script to create the initial content tree. This includes virtual portal–specific instances of the following portal resources: Favorites,Administration, Home, Manage Portlets, and Page Customizer with the corresponding concrete portlets. To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals.


• Assigning default roles and access rights to subadministrators and users on the created resources.

Resources that are nots coped at Virtual portal level

• 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 which are defined in the portal property files apply for the entire portal installation. You cannot specify separate settings for individual virtual portals.


• If you want to make use of the single signon feature that is provided by WebSphere Application Server, you have to 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 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. Example: In a virtual portal that uses the friendly 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.


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


• You 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. For details about how to create URLs refer to Creating custom links to portlets and pages.

Creating Virtual Portal

You have two options for creating virtual Portal

Use Virtual Portal Manager Portlet

Click on the "New Virtual Portal" button in the Virtual Portal Manager portlet. You will get a screen like this



Enter the appropriate values on this screen and click ok.

Use create-virtual-portal task

You can use the ConfigEngine.sh create-virtual-portal task to create virtual portal. Please note one important point that when you create a virtual portal using configuration task, portal will create blank/empty virtual portal.

If you want to use Configuration task then you have two options either you set all the configuration parameters on the command line using -D parameter or set values in C:\WebSphere\wp_profile\ConfigEngine\config\helpers\virtual_portal.properties file and pass absolute path of this helper file to ConfigEngine using -DparentProperties=<pathofvirtualportal.properties> command line parameter

While creating virtual portal, you will have to set these properties

• Virtual Portal title: Title for the virutal portal, it is used to display the virtual portal name in VIrtual Portal Manager portlet, it is not displayed to end users


• Virtual Portal description: Description of virtual portal


• URL Context: URL for accessing virtual portal. This URL is mapped to the actual internal URL of the virtual portal.


• hostname: The hostname of the virtual portal. This attribute is optional. Use it to add a hostname of your choice for the virtual portal


• User realm:The realm that represents the user population for the virtual portal. This field is only shown if your portal configuration supports realms.


• Initial admin user group:The user group of subadministrators who will be able to administer the virtual portal.


• Default theme:The theme of the virtual portal.

Preconfiguring the subadministrators for virtual portals

When you create a new virtual portal using Virtual Portal Manager Portlet, it also takes care of accessing appropriate role to the sub administrator of the virtual portal.



It will read value of portletListNeedAccess which is list of portlet names and will assign role defined by actionSetName to subadminister on all the portlets in the list. In default configuration it will assign Editor role to subadminister on all the portlets defined in portletListNeedAccess list.

You can change these configuration parameters using "Manage Portlet" portlet, you can change either value of actionSetName to some other role such as Manager, Administrator,.. or add remove portlet names from portletListNeedAccess

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.

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:

If you use the configuration task create-virtual-portal to create a virtual portal, this configuration task does not assign roles to the subadministrators of the virtual portal. In this case assign the required roles manually or by using the portal XML configuration interface. For more information about the XML configuration interface and how to use it refer to the XML configuration interface topic.

Populating Virtual Portal

When you create the virtual portal by using the Virtual Portal Manager portlet, the virtual portal is pre-filled with default content. This default content is determined by the default XML script file for initializing virtual portals.


You can change name of this file by clicking on Edit Shared Settings button for Virtual Portal Manager Portal. The value of "xml script to create virtual portal content here" defines which XML script file should be used to configure content of VP. In my case its the default file initVirtualPortal.xml. The actual XML Access Script file is located in was_profile_root/installedApps/cellname/wps.ear/wps.war/virtualportal. If you go to this directory you will notice that there are 4 templates that you can choose from

1. InitAdminVirtualPortal.xml


2. InitFullVirtualPortal.xml


3. InitVirtualContentPortal.xml


4. InitVirtualPortal.xml

In addition to this you can create your own template or modify the existing template. 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).

ONce you have your template ready copy that file in was_profile_root/installedApps/cellname/wps.ear/wps.war/virtualportal folder and specify name of the template file on the Edit Shared Settings. Thereafter whenever you create a new virtual portal using Virtual Portal Manager portlet, this template will be used

When you create a virtual portal, the portlets associated with IBM® Lotus Web Content Management are not included in the virtual portal, even if you have deployed these portlets as part of your original portal installation. To use any of these portlets in a virtual portal, you must manually create a page and add the portlets:

* Authoring portlet: Select Web Content Authoring when adding the portlet.
* Local or Remote Rendering portlet: Select Web Content Viewer when adding the portlet

Virtual Portal Realm

WebSphere Portal has this concept of realms based on federated repository. Realm allows you to create sub group of users from all your repositories, Ex. you can create a realm which only has users from say File System based User Repository or create a Second realm that only has users from one of your LDAP server. Once you create this realm you can attach it to virtual portal so that only users from that sub group can login into the virtual Portal.

Ex. In your organization you have 2 LDAP's one IBM Tivoli directory server is maintained by sales team that has entries for all the employees from Sales department. The finance team is using say Active directory server that has entries for Finance department employees. Now you want to configure your Portal Server to host one Virtual portal for Sales team and one virtual portal for Finance team. You want to configure it so that only employees from Sales team would be allowed to login into sales virtual portal and employees from Finance team would be allowed to access Finance portal. There is third employee virtual portal that both finance and sales team employees can access.

You can use Federated repository + Realms to solve this use case. By default portal is configured to use Federated User repository and it has only one File base user repository as it is member, you can configure it to add both sales and finance department LDAP user repository under the federated user repository. Once that is done you can create 3 different realms one is Sales Realm which is configured to use Sales LDAP Server, other would be Finance Realm that would be configured to use only user from finance ldap and third would be employee realm that contains users from both Sales and Finance LDAP. Once this is done you can create 3 virtual portal and use appropriate realms for them

These are some of the important points related to realms

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


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


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


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

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 your portal instance against your user backend repositories you can use tasks provided by the portal to configure the realms


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 your portal installation.

User Population for virtual portal

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

• 
  Federated repository Using the virtual member manager that is integrated with WAS. VMM allows you to create a user registry based on LDAP or database. You can use VMM in two ways
  
  
  
  • Configure separate user populations for each of your virtual portals.
  
  
  • Use a common user population for all virtual portals. In this case all the users in the user population can login into every virtual poral on that installation. But if you dont want that then you can change it using Portal Access Control
  
  
  
  


• 
  Light weight directory access protocol: If you want to use user repository based on single LDAP server for all the virtual portals in your installation you can use this opion.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. In order to achieve access restrictions for specific virtual portals, you can use the Portal Access Control portlets
  

Virtual Portal Resource Scope

When it comes to scope of resource, by which i mean who can access and modify resource, the portal resources can be divided into three categories

Separating and sharing resources between virtual portals

These resources are scoped at the level of virtual portal. They cannot be accessed or changed from outside the virtual portal.

• Portal Pages


• Portlet instances


• Portal Search Engine search services and search collection. THis includes search content sources


• Composite applications and templates

If your using different user population for virtual portal then you can assign only vp users the access to these resources.

Portal resources that you can separate for virtual portals by using Portal Access Control

These are the resources that are shared by all the virtual portals on that installation.

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

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

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


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

When you update a portlet application it affects all the virtual portal. If you change configuration level preference for a portlet it will also affect all the instances of that portlet in all the virtual portals, you can work around this problem by creating copies of the portlet and setting configuration parameter for particular copy.

Portlet instance is scoped at the level of virtual portal that means if you set change preferences using edit shared settings or edit option then those changes would be local to the virtual portal.

Personalization is not aware of virtual portals. A document library that is 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

What is virtual portal

Virtual portal allows you to create multiple logical portal sites on single portal installation. Each of these virtual portal can be accessed at different URLs such as
http://localhost:10040/wps/portal/vp1 , http://localhost:10040/wps/portal/vp2,..etc and you can configure different pages, configured to display different portlets on each of these virtual portals.

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

You can use concept of realms to configure different user population for each of the
virtual portal and on the administration side either you can assign separate
administrator for each of the virtual portal or same set of administrators can manage
all the virtual portals.

As you can guess virtual portal is logical resource so all the virtual portals share
same JVM. So if one of your virtual portal is resource incentive then it will affect others also they share JVM level resources such as shared library, JNDI COntext (Ex. you cant have different datasources at jdbc/testDataSource context for VP1 and VP2). All different virtual portals will store resource information in same database

When to use virtual portal

• Multiple departments or teams in your organization want their own portal but they dont expect to use them heavily


• Even if your going to host only one portal per installation it might be good idea to create one vp on the portal installation and use it instead of setting it up on the base/true virtual portal. It makes administration little easy