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.
Thanks for this wonderful explanation. I've a question lated to this post. You have mentioned
ReplyDelete"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?
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 :
ReplyDeletePORTAL 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.
what is fantastic post? this is so chock full of useful information I cannot wait to dig deep and start utilizing the resource give me.your exuberance is refreshing.
ReplyDeletePortal development Travel portal development Travel white label Travel Portal Solution B2C Travel Portal B2B Travel Portal Flight Booking API System Flight api integration
Appreciable Content. Keep Sharing
ReplyDeleteVirtual Employee has its advantages. It reduces the cost of the company like equipment, travel expenses, insurance expenses, air conditioning, and many more.
Virtual Employee
Hire proficient Virtual Employee tea at IOGOOS Solution who also work in this corona epidemic and deliver projects with satisfaction.
ReplyDeleteVirtual Employee
staple content related Virtual Employee.
ReplyDeleteHi, Your Post is so impressive and very informative. Thanks for sharing great Information.
ReplyDeleteWeb Portal Development Companies In Bangalore | Web Portal Design Bangalore | Internet Marketing Company in Bangalore | Ecommerce Web Portal Development Bangalore