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

• Use the VMM that is integrated with WebSphere Application Server; it is also known as the Federated Repository. We can use the Federated Repository to set up both types of configuration:
  • Configure separate user populations for each of your virtual portals. This option offers a high flexibility for the user management of your virtual portals. With this configuration, we can define an individual user population for each virtual portal.

  • Use a common user population with the VMM for all your virtual portals. In this case, all users of that user population can access all virtual portals, unless their access permissions are explicitly restricted by portal access control settings. To achieve this restriction, define the access permissions manually using the Portal Access Control portlets.

  A user registry can be based on a Lightweight Directory Access Protocol (LDAP) or on a database.

• Use the LDAP. If a single common user repository is sufficient for all virtual portals within the installation, we can continue to use an LDAP in your virtual portal setup. This is the simpler one of the two options.

  With this configuration the entire portal installation and all virtual portals share a common user population, which is defined in a single user repository. In this case all users of that user population can access all virtual portals, unless their access permissions are explicitly restricted by portal access control settings. In order to achieve access restrictions for specific virtual portals, we can use the Portal Access Control portlets. We define user groups and assign to them the access permissions to the resources of each virtual portal.

For HCL WebSphere 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 the 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:

• A realm contains the entire user population of one virtual portal.
• Each virtual portal can have its own realm of users that are associated. However, it is also possible that multiple virtual portals can share their user population using the same realm in parallel.

• 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 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 WebSphere 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 the 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 we 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.

Configure 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 WebSphere Portal still supports the WebSphere Application Server Lightweight Directory Access Protocol (LDAP) custom user registry that previous versions of HCL WebSphere Portal used. We can configure it as alternative. Again, this configuration uses a common user repository for all virtual portals without separation between the users of the different virtual portals.

Configure separate user populations for the individual virtual portals

To have the users of your virtual portals that are separated, we 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 we 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 we use the Federated Repositories.

When we use the Federated Repositories, we can separate user groups and administrative users by configuring your virtual portals according to your business requirements. We do this based on the following relationships between user repositories, realms, and virtual portals:

• We can aggregate users and groups from one user registry in one realm, and expose them as one coherent user population to the portal installation. We can separate the user population of each virtual portal by assigning different LDAP suffixes to the different realms. The LDAP suffixes are called base entries. This way the concept of realms allows you various flexible configuration options.

• 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. 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 using Federated Repositories, the initial portal installation has no realm that is associated by default. The user population of the initial portal installation spans the entire user registry that we configured in the Virtual Member Manager.

• The individual user IDs must be unique across all realms.

• To log in to a virtual portal, the virtual portal administrator and all users must be a member of the realm for that virtual portal. To allow a user access to more than one virtual portal, that user (and 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 that are associated with these virtual portals. For example, this information applies to a super administrator who is responsible for all virtual portals within an entire Portal installation.

• To administer a virtual portal, the base portal administrator must be a member of the realm that is associated with the virtual portal. The base portal administrator is required to be part of all realms.

  If the administrator is not a part of the virtual portal realm, then the administrator does not have access to that virtual portal. This also applies to the base portal administrator group. If the portal administrator is not part of all realms, then we might encounter issues or the inability to complete certain tasks. For example, a portal installation with virtual portals cannot be migrated, if the portal administrator cannot access the virtual portals for the migration.

• User populations of realms can overlap. In other words, users can be members of multiple realms. If realms overlap, then these users can work in all the virtual portals that are associated with these realms.

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

Resources > Resource Environment > Resource Environment Providers > JCR ConfigService PortalContent > Custom properties > jcr.admin.uniqueName

For example, we can set up the following configurations:

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

• We can configure separate LDAP suffixes that contain different user populations, for example dc=bank1,dc=com for Bank_1 and dc=bank2,dc=com for Bank_2.

Notes:

Considerations for deleting resources in virtual portals:

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 we delete 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 information 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:

• Role members for shared resources who belong to the realm of the virtual portal where we are currently working are listed by their actual names.
• 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.

Find the list of role members. Click the Administration menu icon. Then, click Access > Resource Permissions. From the list of Resource Types, select a Resource Type by clicking it. On the Resource Permissions page, click the Assign Access icon. The members are listed in the Roles column.

How to grant virtual portal administrators access to web content libraries:

Virtual portal administrators do not automatically have access to work with web content libraries when we use the administration portlet. To enable a virtual portal administrator to work with web content libraries, we need to assign them access to either the JCR content root node or individual web content libraries:

• We can assign virtual portal administrators access to the JCR content root node with Set access on root in the Web Content Library view of the Administration portlet. For more information, go to the portlet online help.

  • 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 that they created.

• We can also assign virtual portal administrators access to libraries they did not create by editing the access settings of individual libraries.

Parent topic: Plan for virtual portals

• Securing
• Configure
• Realm support
• Controlling access
• Virtual Member Manager integration
• Add realm support
• Manage the users of virtual portals

References: