+

Search Tips   |   Advanced Search

Managing the user population for virtual portals

You have two basic options for the management of user populations for your virtual portals: Virtual Member Manager (VMM) or Lightweight Directory Access Protocol (LDAP).

This depends on whether we want separate user populations for your virtual portals or a simple solution with one user population for all virtual portals:

For HCL Portal installations, the Federated Repository option offers you more flexibility for the user management of virtual portals. By using the VMM, 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 the VMM and realms in the context of virtual portals. For a wider overview of portal security see the topics about Securing and Configuring the portal and about access permissions, users and groups. For information about how to configure the VMM and realms see the topics about adding realm support for your environment.

A virtual portal can only be accessed by members of its associated user population. By using Portal Access Control that we can assign and restrict access permissions 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. We cannot use Portal Access Control to assign access permissions that cross the separation between virtual portals. For example, we 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:


Preparing the user populations for your virtual portals

To use realms for your virtual portals, configure VMM and the realms before creating your 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 HCL Portal is configured with Federated Repositories as User Registry provider. By default only the super realm, or default realm, is configured. After we have configured the portal instance against your user backend repositories, we can use tasks that are 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, read the topics about adding realm support for the portal environment.Using a non-default realm: If you assign a non-default realm to the default virtual portal, ensure that all administrative accounts are available within the non-default realm. If we have Web Content Manager, do not use a non-default realm, as Web Content Manager is not scoped to virtual portals.

The following sections give an overview of example configurations of the VMM for virtual portals. For more information about configuring realms for your virtual portals, read Virtual Member Manager integration.


Configuring a common user population for all virtual portals

In a simple setup, we can use the Virtual 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.

HCL Portal still supports the WebSphere Application Server Lightweight Directory Access Protocol (LDAP) custom user registry that previous versions of HCL 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.


Configuring separate user populations for the individual virtual portals

To have the users of your virtual portals that are separated, you must apply the more advanced setup by using Federated Repositories. Then, configure separate realms for your virtual portals. When users access a virtual portal, the portal installation selects the appropriate realm that is 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 give access permissions only 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 that is used by the portal installation.

Note: This separation of user populations between virtual portals works only with Federated Repositories. The portal supports separate realms and user repositories for virtual portals only when you use the Federated Repositories.

When you use the Federated Repositories, we 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:

Important: The administrator unique ID for the Java Content Repository (JCR) must be a distinguished name (DN) for a super administrator. You specify the administrator unique ID as the value defined in the jcr.admin.uniqueName property. To view this property, log in to WebSphere Integrated Solutions Console. Go to...

For example, we can set up the following configurations:

Notes:

References: