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.

2 comments:

Apps said...

Thanks for this wonderful explanation. I've a question lated to this post. You have mentioned

"The individual user IDs must be unique across all realms" and later

"User populations of realms can overlap. In other words, users can be members of multiple realms"

If the user population of realms can overlap then we cannot make sure that userid is unique across the realms right? Could you please let me know?

Anonymous said...

Hi,Good explanation. I have a problem after creating a virtual portal, exactly is in the moment of use visibility rules, is logging this error, can you help me. I'm working in this way :

PORTAL 1 -> reaml dc=Empresa, dc=com
PORTAL Virtual 1 -> base entry dc=Empresa2, dc=com
PORTAL Virtual 2 -> base entry dc=Empresa2, dc=com

0000004e SystemErr R Caused by: com.ibm.wps.ac.PrincipalNotFoundException: EJPSB0027E: The principal with ID [ExtIDImpl 'Z9eAeN1P66HH623D0JMO613C8JM46GPC0JM074JC4MMOC5JP26Q4CMHP6JH5C53', USER, 7dcb4b40-6a04-1030-8d2b-fefa4a6f3cae, [Domain: rel]] could not be found.
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.ACPrincipalPumaImpl.retrievePublicPumaPrincipal(ACPrincipalPumaImpl.java:384)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.ACPrincipalPumaImpl.getPublicPumaPrincipal(ACPrincipalPumaImpl.java:227)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.PACGroupManagementServiceImpl.retrieveGroupsFromPuma(PACGroupManagementServiceImpl.java:392)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.PACGroupManagementServiceImpl.retrieveGroupsFromCache(PACGroupManagementServiceImpl.java:355)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.PACGroupManagementServiceImpl.getNestedGroups(PACGroupManagementServiceImpl.java:204)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.services.ac.groupmanagement.PACGroupManagement.getNestedGroups(PACGroupManagement.java:42)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.ACPrincipalPumaImpl.getNestedGroups(ACPrincipalPumaImpl.java:231)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.GroupHelper$2.run(GroupHelper.java:262)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.ac.impl.GroupHelper$2.run(GroupHelper.java:233)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.um.PumaEngineHelper.runUnrestricted(PumaEngineHelper.java:1374)
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R at com.ibm.wps.um.PumaEnvironmentImpl.runUnrestricted(PumaEnvironmentImpl.java:176)
...
[6/2/15 9:55:38:458 ECT] 0000004e SystemErr R Caused by: com.ibm.wps.um.exceptions.impl.MemberNotFoundExceptionImpl: com.ibm.portal.WpsException: EJPSG0002E: Requested Member does not exist.