  
 |
Federated searches allow you to establish search relationships with other sources (including other portals, web sites, or custom databases). Federated searches provide end users a single interface and unified result set for searches over multiple AquaLogic Interaction portals, as well as parallel querying of external internet and intranet-based search engines.
Search web services allow you to specify general settings for your remote search repository, leaving the security settings to be set in the associated outgoing federated searches. This allows you to segregate access to your search repository through multiple outgoing federated searches.
If there is a non-portal repository that you want to search, BEA or another vendor might have written a search web service to access it. If not, BEA provides an IDK that enables you to write your own search web services in Java or .NET. For details, refer to the BEA AquaLogic User Interaction Development Center.
One AquaLogic Interaction portal can request and/or serve content to another AquaLogic Interaction portal. When you install the portal, the Public Access incoming federated search is created. This allows other AquaLogic Interaction portals to search this portal as the Guest user.
What portal identification name and password will be used to identify the portals?
For every request issued, the requesting portal sends an ID and password to identify itself to the serving portal. You must enter the same ID and password in both the requesting portal's outgoing federated search and the serving portal's incoming federated search.
What content from the serving portal will be available to the requesting portal?
If both portals share a common external database of users, such as an LDAP server or Active Directory domain, and those users have been imported into both portals, grant the shared users access to the appropriate content on the serving portal. This provides the greatest degree of content security without requiring any additional administrative work.
If the portals do not share a database of user information, users from the requesting portal must impersonate users from the serving portal. Because impersonation is specified on a group basis (that is a group from the requesting portal is set to impersonate a user from the serving portal), you should create a different serving portal user for each requesting portal group that needs access to different content in the serving portal.
The serving portal can also allow unauthenticated users to search the portal as the Guest user.
After you and the other administrators involved have determined how this relationship will work, you are ready to establish your incoming or outgoing federated searches.
For an example of how requesting portal users can impersonate serving portal users to gain access to secured content, see Example of Impersonating Serving Portal Users.
To learn how multiple portals accessing the same user repository can share content, see Building a Composite Portal with Federated Searches.
   |