Manage the user population for virtual portals
Virtual Member Manager (VMM) allows us to separate user populations for our virtual portals. The VMM integrated with WAS is also known as the Federated Repository. We can...
- Configure separate user populations for each of the virtual portals.
- Use a common user population with the VMM for all the virtual portals.
If a single common user repository is sufficient for all virtual portals within the installation, we can continue to use an LDAP in the virtual portal setup. 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. To achieve access restrictions for specific virtual portals, use the Portal Access Control portlets. We define user groups and assign to them the access permissions to the resources of each virtual portal.
The Federated Repository option in VMM allows us to limit the usage of a particular virtual portal to a specific user population. This is achieved by introducing the concept of realms. A virtual portal can only be accessed by members of its associated user population. By using Portal Access Control 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 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 associated with that virtual portal.
Prepare the user populations for the virtual portals
Configure Virtual Member Manager and the realms before creating the 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 created 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 configuring the portal instance against the user backend repositories, use tasks provided by the portal to configure the realms 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.
Use 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 WCM is not scoped to virtual portals.
Configure a common user population for all virtual portals
In a simple setup, 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.
Configure separate user populations for the individual virtual portals
To have the users of the virtual portals that are separated, apply the more advanced setup using Federated Repositories. Then, configure 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 give access permissions only to users and groups in the population of that virtual portal. Therefore, when creating a virtual portal, the realm representing the population of the new virtual portal must be a subset of the realm used by the portal installation.
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 the virtual portals according to the 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.
- 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 we 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 we configured in the VMM.
- 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 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 information applies to a super administrator who is responsible for all virtual portals within an entire Portal installation.
- 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, then these users can work in all the virtual portals associated with these realms.
The administrator unique ID for the Java Content Repository (JCR) must be a distinguished name (DN) for a super administrator. We specify the administrator unique ID as the value defined in the jcr.admin.uniqueName property.
To view this property, log in to WAS 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 containing different user populations, for example...
dc=bank1,dc=com
...for Bank_1 and...
dc=bank2,dc=com
...for Bank_2
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 you 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 the 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.
You find the list of role members in the portal information center under...
Administration | Access | Resource Permissions | Select Resource Type | Assigning Access for a resource | Edit Role
...under the first column Members in the Role.
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...
...in the Web Content Library view of the Administration portlet.
- 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 created.
- We can also assign virtual portal administrators access to libraries they did not create by editing the access settings of individual libraries.
Parent Plan for virtual portals
Related :