WebSphere Portal, Express Beta Version 6.1
Operating systems: i5/OS, Linux,Windows

 

Planning for virtual portals

Before you create your virtual portals, review this information for planning purposes. Determine how many virtual portals your business requires, and how and for which purposes you will use them. Based on your decision, plan how you implement and configure your virtual portals.

This topic has the following sections:

 

Separating and sharing resources between virtual portals

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

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

The differences in scoping portal resources are described in the following sections.

 

Portal resources that are scoped for virtual portals

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

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:

 

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:

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

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. The following list shows portal resources that you cannot separate for virtual portals:

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.

 

Separating portlets and portlet applications

Separating portlet applications

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

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

If you 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 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: 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:

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.

 

Managing the user population for virtual portals

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

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

delete me The following sections give overview information of how to use Member Manager and realms in the context of virtual portals.

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:

For more details about how to prepare Member Manager and realms for your virtual portals, refer to the next section.

 

Preparing the user populations for your virtual portals

If you plan to use realms for your virtual portals, you need to configure Member Manager and the realms prior to creating your 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 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.

You configure the Member Manager Custom User Registry after the portal installation when you enable the Custom User Registry. WebSphere Portal Express does not provide a configuration task for doing this. You configure the realms manually in the configuration file wmmur.xml. The location of the file is described in the following:

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.

delete me For more details about how to configure Member Manager and realms for your virtual portals refer to the appropriate section in this documentation. Review the sections about the Configuration and Sample Configuration. These sections list samples of the required xml files.

 

Configuring a common user population for all virtual portals

In a simple setup you 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 Express Version 6.1 still supports the WebSphere Application Server Lightweight Directory Access Protocol (LDAP) custom user registry that previous versions of WebSphere Portal Express 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.

 

Configuring separate user populations for the individual virtual portals

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

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

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

For example, you can set up the following configurations:

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

You find the list of role members in the portal information center under AdministrationAccessResource PermissionsSelect Resource TypeAssigning Access for a resourceEdit Role, under the first column Members in the Role.

 

Planning 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

As mentioned before, you can scope some portal resources for your virtual portals by using portal administration and Portal Access Control. For example, this applies to portlet applications. These resources are available to all virtual portals. You can scope these resources to specific virtual portals by limiting their accessibility to the user populations of the required virtual portals. To do this, you use Portal Access Control. Resources that you scoped this way for one virtual portal cannot be accessed from other virtual portals.

Portal Access Control provides a flexible concept to grant certain users or user groups access privileges to specific pages and other resources of a portal. A super administrator can delegate a subset of the administration privileges to other administrative users. You can use this flexibility to enable separation between different virtual portals in the following ways:

The inheritance concept of Portal Access Control allows this setup. The combination of access rights that a subadministrator has on portal resources and on users and groups defines the scope of the virtual portal of that subadministrator:

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 Express 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. For more details about both of these tools refer to Administering virtual portals.

The Virtual Portal Manager portlet is installed as part of the initial portal installation. You 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 Portal Access Control or can define realms in the Member Manager configuration files.

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 you 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 Portal Access Control.

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:

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

Note: 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 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 your portal refer to WSRP services, and other portals can integrate the WSRP services as remote portlets for their users.">Using WSRP services.

For more detail about Portal Access Control refer to Other Configuring information - title & description will change. For more detail about virtual portal security refer to Portal Access Control 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. If you want 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. For details about how to do this refer to Preconfiguring the subadministrators for virtual portals.

You can also assign additional access rights on portal resources to the virtual portal subadministrators. For example, you might want to add the following access rights:

If you want to assign additional access rights to the subadministrators after creating a virtual portal, use the master administrator user ID of your 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, the XML configuration interface, or the Portal Scripting Interface. The consequences differ, depending on where you make the updates:

 

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

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

If you want to change these default roles and the access rights for the users, you can do this by one of the following ways:

 

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 the portal.Note: As the portal is constantly being developed and improved, the virtual portal content of your portal might be more up to date than the following list.

Content (wps.content.root). This includes the following pages and portlets:

Note: 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. 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 subadministrators of the virtual portal:

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

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.

If you want to change the content of virtual portals, you can do this by one of the following ways:

 

Shaping the user experience

The following sections describe how you can shape the user experience that users have with your virtual portals.

 

User friendly URL mappings for virtual portals

You can provide user friendly URLs for your users to access their virtual portals. For example, you can give each virtual portal a friendly URL, such as http://www.ibm.com:10038/wps/portal/tivoli. You can pass the friendly 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 friendly URL as required by your 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. The XML configuration interface 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 the administration portlets URL Mapping or Custom Unique Names or the XML configuration interface to make the change.

  3. If you use an external security manager, such as Tivoli Access 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 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.

  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 Express

Besides virtual portals, another possible configuration may be an alternative for you, depending on your 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 WebSphere Application Server installation. These are the main advantages of true portals:

If you want to implement this solution, be aware of the following limitations:

 

Related information

Parent topic: Multiple virtual portals Parent topic: Planning for virtual portals
Library | Support | Terms of use |