Skip Headers
Oracle® Secure Enterprise Search Administrator's Guide
11g Release 2 (11.2.2)

Part Number E23427-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

Setting Up Federated Sources

Secure federated search enables searching secure content across distributed Oracle SES instances. An end user is authenticated to the Oracle SES federation broker. Along with querying the secure content in its own index, the federation broker federates the query to each federation endpoint on behalf of the authenticated end user. This mechanism necessitates propagation of user identity between the Oracle SES instances. In building a secure federated search environment, an important consideration is the secure propagation of user identities between the Oracle SES instances. This section explains how Oracle SES performs secure federation.

To create a federated source: 

  1. On the Home page, select the Sources secondary tab to display the Sources page.

  2. For Source Type, select Federated.

  3. Click Create to display the Create Federated Source page.

  4. Complete the following fields. See "Federation Trusted Entities" and click Help for additional information.

    • Source Name: Name that you assign to this federated source.

    • Web Service URL: The URL for the Web service.

    • Remote Entity Name: Name of the federation trusted entity on the federation endpoint.

    • Remote Entity Password: Password for Remote Entity Name.

    • Search User Attribute: Attribute used to authenticate users on the federation endpoint instance.

    • Filter Rule: Conditions for routing queries to this federated source. Filter rules can improve scalability. If no rule is defined, then the federation agent sends all queries to the federated source to perform the search.

  5. Click Create or Create & Customize.

  6. Follow the steps for crawling and indexing a source in "Getting Started Basics for the Administration GUI".

To customize a federated source: 

  1. When creating a federated source, click Create & Customize on the Create File Source page to display the Customize File Source page.

    or

    After creating a source, click the Edit icon on the Home - Sources page.

  2. Click the following subtabs and make the desired changes. See "Customizing Federated Sources".

    • Basic Settings: Source name, Web Service URL, and so forth.

    • Search Restrictions: Controls whether the search is restricted, and if so, which source groups are searched.

    • Attribute Retrieval: Lists search attributes to retrieve at query time.

    • Attribute Mapping: Maps local and remote search attributes.

  3. Click Apply.

Federation Trusted Entities

When performing a secure search on a federation endpoint, the federation broker must pass the identity of the logged-in user to the federation endpoint. If the endpoint instance trusts the broker instance, then the broker instance can proxy as the end user. To establish this trust relationship, Oracle SES instances should exchange some secret. This secret is exchanged in the form of a trusted entity.

A trusted entity consists of two values: entity name and entity password. Each Oracle SES instance can have one or more trusted entities that it can use to participate in secure federated search. (A trusted entity is also referred to as a proxy user.)

An Oracle SES instance can connect to an identity management (IDM) system for managing users and groups. An IDM system can be an LDAP-compliant directory, such as Oracle Internet Directory or Active Directory.

Each trusted entity can be authenticated by either an IDM system or by the Oracle SES instance directly, independent of an IDM system. For authentication by an IDM system, check the box Use Identity Plug-in for authentication when creating a trusted entity. In this case, the entity password is not required. This is useful when there is a user configured in the IDM system that can be used for proxy authentication. Ensure that the entity name is the name of the user that exists in the IDM system and is going to be used as the proxy user.

For authentication of the proxy user by Oracle SES, deselect Use Identity Plug-in for authentication when creating a trusted entity. Then use any name and password pair to create a trusted entity.

Use Authentication Attribute to specify the format of the user credential that the Oracle SES federation endpoint expects for this particular trusted entity in proxy authentication. The identity plug-in registered on the federation endpoint should be able to map this user identity to the default authentication format used on the federation endpoint. This is useful when a federation broker cannot send user identity in the default authentication format used on the federation endpoint for proxy authentication, but the identity plug-in registered on the federation endpoint can map the value from the attribute in which it receives the user identity during proxy authentication to the default authentication format used on the federation endpoint.

To use a proxy entity, use the Web services API proxyLogin user name and password for the entity name and entity password. The identity plug-in can validate the password instead of storing it. When a request is sent for proxyLogin, Oracle SES calls the identity plug-in (which returns the call) to authenticate the entity. The proxyLogin must supply a valid trusted entity registered in the federation trusted entities.

User names are not case sensitive.

To perform secure federated search, both the broker and the endpoint instances involved in the federation must have identity plug-ins registered. The identity plug-ins may or may not talk to the same IDM system.

Note:

All user names should be unique across all Oracle SES instances. If not, then there should be a clear mapping for the users to make them unique across all IDMs involved in the secure federation.

Carefully specify the following parameters under the section Secure Federated Search when creating a federated source on the broker instance:

  • Remote Entity Name: This is the name of the federation trusted entity on the federation endpoint. It is provided by the administrator of the endpoint instance.

  • Remote Entity Password: This is the password of the federation trusted entity on the federation endpoint. It is provided by the administrator of the endpoint instance.

  • Search User Attribute: This attribute identifies, and is used to authenticate, a user on the federation endpoint instance. This parameter is optional parameter, unless the broker and endpoint use different authentication attributes to identify end users. For example, on the broker instance, an end user can be identified by user name; on the endpoint instance, the end user can be identified by e-mail address.

    The identity plug-in registered on the broker instance should be able to map the user identity to this attribute based on the authentication attribute used during the registration of the identity plug-in. If this attribute is not specified during creation of the federation source, then the user identity on the broker instance is used to search on the endpoint instance.

    Note:

    If these parameters are not specified during the creation of the federated source, then the federated source is treated as a public source (that is, only public content is available to the search users).
  • Secure Oracle HTTP Server-Oracle SES channel: Because any Oracle HTTP Server can potentially connect to the AJP13 port on the Oracle SES instances and masquerade as a specific person, either the channel between the Oracle HTTP Server and the Oracle SES instance must be SSL-enabled or the entire Oracle HTTP Server and Oracle SES instance computers must be protected by a fire wall.

Notes:

  • In a secure federated search environment, the broker or the endpoint instance might or might not be using OracleAS Single Sign-On. However, the Web service URL of the endpoint should not be behind OracleAS Single Sign-On.

  • Oracle strongly recommends that you SSL-protect the channel between Oracle HTTP Server and Oracle SES for secure content. The endpoint instance should be SSL-enabled, or you should be able to access the Web service using HTTPS.

Example Creating a Federated Source

This section describes the steps for setting up a federated source that connects to Active Directory.

  1. Activate the Active Directory identity plug-in on both the endpoint and broker instances. For example, on the Global Settings - Identity Management Setup page, enter the following:

    • Parameter Name: value

    • Directory URL: ldap://ad.oracle.com:389

    • Directory account name: administrator@ad.oracle.com

    • Directory account password: Password for Directory account name.

    • Directory subscriber: dc=ad,dc=oracle,dc=com

    • Directory security protocol: none

  2. Create federation trusted entities on the endpoint instance. For example, login to Oracle SES on the endpoint instance, navigate to the Global Settings - Federation Trusted Entities page, and enter the following:

    • Entity Name: Entity name

    • Entity Password: Password for Entity Name

  3. Create a federated source on the broker side. For example, login to Oracle SES on the broker instance, navigate to the Home - Sources page, select the source type as Federated, and enter the following:

    • Source Name: Sourcename1

    • Web Service URL: http://endpoint.cn.oracle.com:7777/search/query/OracleSearch

    • Remote Entity Name: Entity name

    • Remote Entity Password: Password

  4. To browse the federated source on broker side, create a source group and then add the federated source to the group.

Customizing Federated Sources

On the Home - Sources - Customize Federated Source page, you can change the source name, Web Service URL, remote entity name and password, and search user attribute.

This section describes the other ways you can customize a federated source:

Route Queries to the Federated Source

Enter a filter rule, which sets conditions for routing queries to the federated source, on the Home - Sources - Customize Federated Source page. Filter rules can improve scalability. If no rule is defined, then the federation agent sends all queries to the federated source to perform the search. The rules are applied only against the search query filter. They are not applied when an end user enters the attribute shortcut query.

Each rule has an attribute, a colon (:) and an expression. Rules can be based on end user properties, such as name or e-mail address, and on query information, such as document language, author, or document modified date. For example, an identity attribute could be mail or dn. A query attribute could be author or lastmodifieddate.

Multiple rules for the source are joined with the AND and OR operators. The attribute name and the operators are not case-sensitive. For example, the following rule defines that the federated source is for English documents and for users having an e-mail address starting with A in the identity management system:

(language:en ) AND (idm::mail:a.*)

The attribute can be Date, String, or Number type. For String attributes, the rule expression is regular expression. Oracle SES supports the regular expression syntax used in Java JDK 1.4.2 Pattern class (java.util.regex.Pattern). For Date and Number attributes, the expression contains the operator and value. The operators are =, >, >=, <, <=.

Filter Rule Examples

The following rule defines that the federated source is for documents larger than 1 M:

content-length:>1000000

The following rule defines that the federated source is for documents published after 12/31/2006:

lastmodifieddate:> 12/31/2006

The following example defines that the federated source has only documents for the last week:

lastmodifieddate:> sysdate - 7

The following rule defines that the federated source is for the login name, which could be an attribute of the identity management repository:

username:test00.*

Set Search Restrictions

Restrict search to a specific list of source groups on the Home - Sources - Customize Federated Source - Search Restrictions page.

Available source groups from the federated source are retrieved when the page is loaded. When Source Group Restricted Search is selected, you can move the source groups between the Not Searched and Searched lists. When Unrestricted Search is selected, all source groups on the remote instance are searched.

The Refresh Source Groups button refreshes the available source groups from the remote instance. If a source group is no longer available, then it is marked Not Available. All newly available source groups after a refresh appear in the Not Searched list by default, and all existing source groups remain in the list they are presently in. If a remote source group is renamed, the old name is marked Not Available and the new name appears in the Not Searched list. Unavailable source groups persist while they remain in the Searched list.

If the federated source is unavailable, then the available source groups are loaded from local storage. A warning message then states that Oracle SES cannot retrieve the available source groups from the remote instance, indicating that the available source groups may be out of date.

Note:

A federated source can be restricted to only explicitly-created source groups on the remote Oracle SES instance. For example, a federated source cannot be restricted to the Miscellaneous group on the remote Oracle SES instance.

Retrieve Attributes

Identify which attributes to retrieve from the federated source on the Home - Sources - Customize Federated Source - Attribute Retrieval page.

Available attributes from the federated source are retrieved when the page is loaded. Move search attributes to retrieve between the Not Retrieved column and the Retrieved column. Attributes that are always retrieved by Oracle SES by default are in the Retrieved list and marked Mandatory. These attributes cannot be saved in the Not Retrieved list.

The Refresh Attributes button refreshes the available attributes from the remote instance. If an attribute is no longer available, then it is marked (Not Available). All newly available attributes after a refresh appear in the Not Retrieved list by default, and all existing attributes remain in the list they are presently in. If a remote attribute is renamed, then the old attribute name is marked Not Available, and the new name appears in the Not Retrieved list. Unavailable attributes persist while they remain on the Retrieved list or are used in an explicit attribute mapping.

If the federated source is unavailable, then the available attributes are loaded from local storage. A warning message then states that Oracle SES cannot retrieve the available attributes from the remote instance, so the available attributes may be out of date.

Map Attributes

Map local search attributes with federated search attributes on the Home - Sources - Customize Federated Source - Attribute Mapping page. For example, a local search attribute named Creator can be mapped to a remote attribute named Author. This is an explicit attribute mapping. Only one-to-one mappings between attributes of the same data type are supported.

Note:

For default Oracle SES search attributes, Oracle SES implicitly maps local attributes to remote attributes. For example, a remote attribute named Author is always mapped to local search attribute name Author. For all other attributes, explicit mappings must be created.

Local search attributes are the available attributes on the local instance, as defined on the Global Settings - Search Attributes page. Local search attributes that are used in a mapping cannot be deleted on the Global Settings - Search Attributes page. Initially, there are no mappings.

Remote search attributes are the available attributes on the federated source. This list is retrieved when the page is loaded. If a remote attribute is mapped to a local attribute but the remote attribute is no longer available, then the remote attribute is marked (Not available). Only attribute mappings involving available remote attributes are used during queries.

Tips for Using Federated Sources

  • The Oracle SES federator caches the federator configuration (that is, all federation-related parameters including federated sources). As a result, any change in the configuration takes effect within five minutes.

  • If you entered proxy settings on the Global Settings - Proxy Settings page, then add the Web Services URL for the federated source as a proxy exception.

  • If the federation endpoint instance is set to secure mode 3 (require login to search secure and public content), then all documents (ACL stamped or not) are secure. For secure federated search, create a trusted entity in the federation endpoint instance, then edit the federated source with the trusted entity user name and password.

  • There can be consistency issues if you have configured a BIG-IP system as follows:

    • You have two Oracle SES instances configured identically (same crawls, same sources, and so on) behind a BIG-IP load balancer to act as a single logical Oracle SES instance.

    • You have two other Oracle SES instances configured identically along with Oracle HTTP Server and OracleAS Web Cache fronting each one and both servers behind BIG-IP. Each of these two instances federate to the logical Oracle SES instance. Web Cache is clustered between these two nodes to act as a single logical Oracle SES instance called broker instance.

    When a user performs a search on the broker Oracle SES instance and tries to access the documents in the result, document access may not be consistent each time. As a work-around, ensure that the load balancer sends all the requests in one user session to the exact same node each time.

Looping Among Federated Sources

A federation loop or cycle refers to a deployment in which multiple SES instances federate to each other. For example, if SES Instance A federates to SES Instance B, and SES Instance B federates back to instance A, then a federation cycle is in the deployment. Federation cycles can cause a flood of queries and high CPU load on the participating SES instances.

SES does not detect federation cycles, thus the Oracle SES administrator is responsible for avoiding them. You can explicitly remove them from the deployments or use source-group-restricted federation. The previous example can be fixed with a source-group restriction: the source groups on Instance B selected for federation on Instance A do not have any federated sources for Instance A, and the converse. See "Set Search Restrictions".

Federated Search Characteristics

  • Federated search can improve performance by distributing query processing on multiple computers. It can be an efficient way to scale up search service by adding a cluster of Oracle SES instances.

  • The federated search quality depends on the network topology and the throughput of the entire federated Oracle SES environment.

Federated Search Limitations

  • There is a size limit of 200KB for the cached documents existing on the federation endpoint to be displayed on the Oracle SES federation broker instance.

  • For infosource browse, if the source hierarchies for both local and federated sources under one source group start with the same top level folder, then a sequence number is added to the folder name belonging to the federated source to distinguish the two hierarchies on the Browse page.

  • For federated infosource browse, a federated source should be put under an explicitly created source group.

  • On the Oracle SES federation broker, there is no direct access to documents on the federation endpoint through the display URL in the search result list for the following source types:

    • File (local files, not UNC)

    • Table

    • E-mail

    • Mailing list

    For these source types, only the cached version of documents is accessible.