  
 |
This example shows how a search relationship might be set up between two separate portals.
The fictional company Servicor wants to share content with its fictional partner Requesticon. In this case, Servicor's portal is the serving portal, and Requesticon's portal is the requesting portal.
First, the administrator of the Servicor portal creates two portal users: Requesticon Engineer and Requesticon Executive. Both of these users are added to the portal group named Requesticon Visitors.
These users are then individually granted access to appropriate content on the Servicor portal. Requesticon Engineer is granted Read access to the Engineering, QA, and Product Management folders of the Servicor Knowledge Directory. Requesticon Executive is granted Read access to the Servicor Market and Investor Relations folders.
The administrator of the Servicor portal then sets up an incoming federated search. On the Main Settings page of the Incoming Federated Search Editor, the Servicor portal administrator includes the AquaLogic Interaction Authentication Source and the group Requesticon Visitors. The AquaLogic Interaction Authentication Source is included because the Requesticon Engineer and the Requesticon Executive users were both created in the portal; had they been imported through another authentication source, then that authentication source would need to be included instead. The Requesticon Visitors group is included here to prevent users of the requesting portal from attempting to impersonate any user other than Requesticon Engineer or Requesticon Executive.
With the serving portal configured this way, only requests issued by Requesticon Engineer and Requesticon Executive are answered, and only appropriate content is visible.
On the Main Settings page of the Outgoing Federated Search Editor, the administrator of the Requesticon portal selects Yes for Send portal authentication. Then, under User Name Aliasing, the Requesticon portal administrator maps the group Executives to the Servicor user named Requesticon Executive and the group Engineers to the Servicor user named Requesticon Engineer. This way, all users that are members of the Engineers group impersonate Requesticon Engineer when issuing requests, and all users that are members of the Executives group issue requests as Requesticon Executive.
When a requesting user tries to search a serving portal, the requesting portal examines the list of mapped groups from the top down; the first group in the list to which the requesting user belongs is used to determine what serving portal user the requesting user will impersonate. Therefore, groups with high levels of security should be mapped at the top of the list. The requesting portal administrator made sure to add the Executives group before the Engineers group so that if any user on the requesting portal is a member of both the Executives group and the Engineers group, then that user will impersonate the Requesticon Executive user. Being an executive, this user is likely to be granted access to more content.
   |