| Oracle® Secure Enterprise Search Administrator's Guide 11g Release 1 (11.1.2.0.0) Part Number E14130-04 |
|
|
View PDF |
| Oracle® Secure Enterprise Search Administrator's Guide 11g Release 1 (11.1.2.0.0) Part Number E14130-04 |
|
|
View PDF |
This chapter describes the architecture and configuration for Oracle SES security model. It contains the following topics:
This section describes the Oracle SES security model. It contains the following topics:
Oracle SES provides access to a variety of content repositories through a single gateway. Each external repository has its own security model that determines whether a particular user can access a particular document. You must carefully consider all aspects of security in Oracle SES to respect the security of documents coming from multiple data repositories.
Oracle SES uses the following security services in its security model:
Identity plug-ins can obtain user and group information directly from any identity management system. An identity plug-in is Java code between Oracle SES and an identity management system, allowing Oracle SES to read user and group information.
Secure Socket Layers (SSL) is the industry standard protocol for managing the security of message transmission on the Internet. This is used for securing RMI connections, HTTPS crawling, and secure JDBC.
Connecting to the Oracle SES server using SQL*Plus, except as documented in the guide, is not supported. Changing the Oracle SES server directly using SQL and modifying initialization parameter files is not supported. User management, including password changes, should only be done using the Oracle SES Administration GUI.
As an additional security measure, Oracle SES is configured to reject connection requests using SQL*Plus from remote hosts. The only protocols supported for connection to Oracle SES from remote hosts are HTTP, HTTPS, and AJP13.
The user name for Oracle SES is eqsys. You can change the password specified during installation on the Global Settings - Change Password page. A password must consist of at least 8 characters, and contain at least one numeric and one alphabetic character. Note that the password length cannot exceed 30 characters. After you click Apply, a confirmation message appears if the password changed successfully.
For added security, a temporary password feature is provided. You can enter login credentials for use by the crawler when creating table sources, e-mail, OracleAS Portal, or Web sources. For Web sources, authentication can be performed with HTTP authentication, HTML forms, and OracleAS Single Sign-On.
To use the temporary password feature:
Select the Delete Passwords After Crawl option in the Oracle SES Administration GUI when creating or editing a source.
This option is not available when self service for Web sources is enabled.
If a source has the Delete Passwords after Crawl option enabled, then you are prompted for all required passwords whenever the schedule for that source starts. You must start these schedules manually, which enables you to respond to the prompts. The supplied passwords are removed immediately after the schedule completes.
Oracle SES security is implemented at two levels: user authentication and user authorization.
This section contains the following topics:
User authentication identifies a user through an identity management system. You can register an identity plug-in to any identity management system; Oracle SES provides registered identity plug-ins for many identity management systems. The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Activation is performed on the Global Settings - Identity Management Setup page.
Security filter configuration for the identity plug-in is performed on the Global Settings - Query Configuration page. A login does not force a refresh of the user's security filter. For a query request, Oracle SES checks the timestamp of an existing cached security filter and refreshes it when the specified life span has expired. The default latency is 60 minutes.
User authorization determines whether a user can access information about a particular item in the result list. It can be implemented in two layers.
The first layer utilizes access control lists (ACLs). An ACL lists the users or groups of users that have access to the document. The ACL can be assigned by the administrator to an entire source through the Oracle SES Administration GUI (source-level ACLs), or it can be provided by the source itself for each document (document-level ACLs).
The second layer uses a Java class to dynamically filter documents at search time (query-time authorization).
Oracle SES can use the following types of ACL policies:
Source-level ACLs: An individual source can be protected by a single ACL, which governs access to every document in that source. These ACLs are defined on the Home - Sources - Authorization page.
Document-level ACLs: Oracle SES provides mapped security to repositories by retrieving the ACL for each document at the time of crawling and indexing. At crawl time, the ACL for each document is passed to the crawler along with the document content, and the ACL is stored in the index. Currently Oracle SES supports document-level ACLs for user-defined sources and OracleAS Portal sources. (The ACL policy is Documents Controlled by the Source.) With user-defined sources, ACLs are returned by the crawler plug-in implemented by the user. With OracleAS Portal sources, ACLs are returned by the OracleAS Portal server. At search time, Oracle SES does not need any connection with the repository to validate access privileges.
For both source-level ACLs and document-level ACLs, all users and roles defined in the ACLs must exist in the identity plug-in.
User names are not case sensitive.
Table 11-1 identifies when documents are visible with the document ACL types supported in Oracle SES:
Table 11-1 Document ACL Types in Oracle SES Security Model
| Document ACL Type | Public User | Authenticated User | Authenticated User with Allow Permission to Document | Authenticated User with Deny Permission to Document |
|---|---|---|---|---|
|
No ACL |
document visible |
document visible |
N/A |
N/A |
|
Deny Permission Only |
-- |
-- |
N/A |
-- |
|
Allow Permission Only |
-- |
-- |
document visible |
N/A |
|
Deny with Allow Permissions |
-- |
-- |
document visible |
-- |
Table 11-2 compares the document-level user authorization methods in Oracle SES.
Table 11-2 User Authorization Methods in Oracle Secure Enterprise Search
| Method | How Authorization is Determined | Advantages | Disadvantages |
|---|---|---|---|
|
ACLs |
The ACL is supplied by a crawler plug-in or an OracleAS Portal server. |
Faster secure search performance. No additional programming is required for ACL-based OracleAS Portal security. (If implementing a crawler plug-in, then some additional work is necessary to supply ACLs.) |
ACLs are static: they are updated only when crawling the source repository or when the administrator changes Oracle SES ACLs in the Oracle SES Administration GUI |
|
Query-time Authorization |
|
Dynamic authorization. |
There is performance overhead in cases when the search is not selective, returning large number of rows before query-time authorization. Extra work is required to implement a |
For sources that do not fit the user/group model, an authorization plug-in provides a more flexible security model. With an authorization plug-in, a crawler plug-in can add security attributes similar to document attributes. The authorization plug-in is invoked at login time to build security filters onto the query string. The security filters are applied against the values of the security attributes for each document. Only documents whose security attribute values match the security filter are returned to the user.
See Also:
"Administrator-Based Authorization" for more information about ACLs
"Query-time Authorization" for more information on Java filter classes
On the Home - Sources - Authorization page, you can set and change the ACL policy.
The following ACL policy options are available:
No ACL: With this setting, all documents are considered searchable and visible
Oracle Secure Enterprise Search ACL: With this setting (also known as source-level ACLs), you can protect the entire source with one ACL. The same ACL protects every document in that source.
ACLs Controlled by the Source: This setting (also known as document-level ACLs) is available only for OracleAS Portal sources and user-defined sources. This preserves authorizations specified in OracleAS Portal. For user-defined sources, crawler plug-ins (or connectors) can supply ACL information with documents for indexing, which provides finer control document protection. (That is, each document in the source can have different access privileges.)
The following restrictions apply to changing the ACL policy:
If the schedule associated with the source is not currently being crawled, and if the source has never been crawled, then all ACL policy changes are allowed.
If the schedule associated with that source is currently being crawled (that is, the schedule status is Launching, Executing, or Stopping), then all ACL options are grayed out, and you cannot change the ACL policy.
If the schedule associated with the source is not currently being crawled, but the source has been crawled earlier, then the only change allowed is between No ACL and Oracle Secure Enterprise Search ACL (in either direction). This is visible in the Oracle SES Administration GUI as follows:
If the ACL option selected before the crawl started was No ACL or Oracle Secure Enterprise Search ACL, then the ACLs Controlled by the Source option is grayed out.
If a secure ACL policy was selected but the identity plug-in is deactivated, then you can change the ACL policy to No ACL regardless of the crawl status.
OracleAS Portal sources are subject to the same restrictions as other sources. That is, no changes are allowed while being crawled, and only changes between No ACL and Oracle Secure Enterprise Search ACL are allowed after crawling completes. However, the ACL policy for an OracleAS Portal source can also change if it is inheriting the ACL policy from its OracleAS Portal server parent; for example, when the OracleAS Portal server ACL policy is modified or when the OracleAS Portal source is changed from specifying the ACL policy locally to inheriting it from the server. Therefore, changes on an OracleAS Portal server are restricted so that no disallowed changes can occur on any children that inherit the ACL policy.
If any child inheriting the ACL policy is being crawled, then no changes are allowed on the OracleAS Portal server. If any child inheriting the ACL policy has been crawled, then the only changes allowed are between No ACL and Oracle Secure Enterprise Search ACL. (If the OracleAS Portal server policy is ACLs Controlled by the Source, then no changes are allowed). Similarly, the OracleAS Portal source cannot be set to inherit its ACL policy from the OracleAS Portal server if the associated change in ACL policy would be disallowed.
Note:
A source that is being crawled is different from a source whose associated schedule is being crawled. Oracle SES restricts all ACL policy changes for a source when the schedule associated with that source is being crawled. A source might not be crawled, but the schedule associated with it could be crawled if another source in the same schedule is being crawled.You can register an identity plug-in to any identity management system. Oracle SES provides registered identity plug-ins for many identity management systems. The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Activate an identity plug-in on the Global Settings - Identity Management Setup page.
When you activate a plug-in, the Global Settings - Activate Identity Plug-in page is displayed. When completing this page, be sure that the values for Additional User Base and Additional Group Base are not subsets of Directory Subscriber.
Caution:
You must create the identity plug-in before creating an Oracle SES data source for any type of secure data. If the identity plug-in is not active, then the data source is crawled as a public data source.The following table lists which identity plug-ins are available for each enterprise content source.
Table 11-3 Identity Plug-ins for Enterprise Content Sources
| Source Type | Versions Supported | Identity Plug-in |
|---|---|---|
|
Database |
Any databases with a JDBC driver |
Native |
|
EMC Documentum Content Server |
5.1, 5.2.5, 5.3 SP2 |
Active Directory, Oracle Internet Directory, Native |
|
EMC Documentum eRoom |
7.3 |
Active Directory, Oracle Internet Directory |
|
FileNet Content Engine |
3.5 |
Active Directory |
|
FileNet Image Services |
4.0 (ISRA 3.2) |
Active Directory, Oracle Internet Directory, Native |
|
Hummingbird Document Management Server |
2004, 2005 |
Active Directory, Native |
|
IBM DB2 Content Manager |
8.3 |
Native |
|
Lotus Notes |
5.0.9, 6.5.4,7.0 |
Active Directory, Oracle Internet Directory, Native |
|
Microsoft Exchange |
Windows 2000, Windows 2003 |
Active Directory |
|
Microsoft SharePoint Portal Server |
2003, 2007 |
Active Directory |
|
NTFS |
Windows 2000, Windows 2003 |
Active Directory, Oracle Internet Directory |
|
Open Text Livelink |
9.2, 9.5, 9.5.5 |
Active Directory, Native |
|
Oracle Calendar |
10.1.2 or later |
Oracle Internet Directory |
|
Oracle Content Database |
Oracle Content Services 10.1.2 or later, Oracle Content Database 10.2 or 10.1.3 |
Native, Query-time authorization |
|
Oracle E-Business Suite |
11, 12 |
Native |
|
Oracle Mail |
10g |
Oracle Internet Directory |
|
Siebel 7.8 |
7.8 |
Native |
|
Siebel 8 |
8 |
Native |
|
Oracle Content Server |
7.1.1, 7.5.2, 10gR3 |
Native |
When connecting to Active Directory, Oracle SES tries to resolve the Active Directory domain name to an IP address of the Active Directory Domain Controller. This is generally not possible, especially when Oracle SES is installed on a non-Windows system or on a Windows system in a different domain. You must add the IP address of the Active Directory domain to the host file.
For example, to connect to an Active Directory domain called foobar.example.com, you must add something similar to the hosts file: 10.123.1.2 foobar.example.com. Search for the hosts file in C:\Windows\System32\Drivers\etc\HOSTS on Windows systems, and /etc/hosts on UNIX systems.
For the Active Directory identity plug-in enter values for the following parameters:
Directory URL: ldap://ActiveDirectoryserver:389
Directory account name: UserLogonName Confirm the user logon name on the Active Directory Users and Computers application. Under the User folder, right-click username. Select Property and go to the Account tab. For example, assume the user account adtest in domain domain1.example.com, which is associated with the target Active Directory. You may try domain1\adtest or adtest@domain1.example.com or cn=adtest,cn=users,dc=domain1,dc=example,dc=com if you are not sure the actual user logon name. The user account does not need to be an administrator account.
Directory account password: PasswordForDirectoryAccount
Directory subscriber: dc=domain1,dc=example,dc=com for the domain name domain1.example.com
Directory security protocol: none
If you deactivate an identity plug-in, then you must restart the middle tier with searchctl restart.
If a pre-installed identity plug-in is accidentally removed, you can re-register it with the following steps:
On the Global Settings - Identity Management Setup page, click Register New Identity Plug-in.
Enter the class name and jar file name of the removed identity plug-in, as identified in Table 11-4.
Click Finish.
Table 11-4 Identity Plug-in Class Names and Jar File Names
| Identity Plug-in | Plug-in Class Name | Jar File Name |
|---|---|---|
|
Documentum Content Services |
oracle.search.plugin.security.identity.dcs.DCSIdentityPluginManager |
../dcs/DCSIdentityPlugin.jar |
|
FileNet Image Services |
oracle.search.plugin.security.identity.fnis.FNISIdentityPluginManager |
../fnetis/FNISIdentityPlugin.jar |
|
Hummingbird DMS |
oracle.search.plugin.security.identity.hbdm.HBDMIdentityPluginManager |
../hbdm/HBDMIdentityPlugin.jar |
|
Open Text Livelink Content Services |
oracle.search.plugin.security.identity.llcs.LLCSIdentityPluginManager |
../llcs/LLCSIdentityPlugin.jar |
|
Database |
oracle.search.plugin.security.identity.db.DBIdentityPluginManager |
../oracleapplications/DBCrawler.jar |
|
Oracle E-Business Suite |
oracle.search.plugin.security.identity.ebs.EBSIdentityPluginMgr |
.../oracleapplications/EBSCrawler.jar |
|
Siebel 7.8 |
oracle.search.plugin.security.identity.siebel.Siebel78IdentityPluginMgr |
../oracleapplications/Siebel78Crawler.jar |
|
Siebel 8 |
oracle.search.plugin.security.identity.siebel.SiebelIdentityPluginMgr |
../oracleapplications/Siebel8Crawler.jar |
|
Oracle Content Server |
oracle.search.plugin.security.identity.stellent.StellentIdentityPluginMgr |
../oracleapplications/StellentCrawler.jar |
|
Oracle Internet Directory |
oracle.search.plugin.security.identity.oid.OIDPluginManager |
OIDPlugins.jar |
|
IBM DB2 Content Manager |
oracle.search.plugin.security.identity.icm.ICMIdentityPluginManager |
icm/ICMIdentityPlugin.jar |
|
Active Directory |
oracle.search.plugin.security.idm.IdentityPluginManagerADImpl |
idm/idmPlugin.jar |
|
Sun Java System Directory Server |
oracle.search.plugin.security.idm.IdentityPluginManagerIPlanetImpl |
idm/idmPlugin.jar |
|
OpenLDAP Directory |
oracle.search.plugin.security.idm.IdentityPluginManagerOpenLdapImpl |
idm/idmPlugin.jar |
|
Lotus Notes |
oracle.search.plugin.security.identity.ln.LNIdentityPluginManager |
ln/LNIdentityPlugin.jar |
The information Oracle SES saves from the identity plug-in (that is, the correspondence between names and canonical attribute values) may not be valid on different identity plug-ins. If you keep the same identity plug-in server (for example, to change port numbers or to switch to SSL), or if you use a new directory server that has identical user information, then you can deactivate and re-activate the identity plug-in anytime without restriction. This section describes steps you must perform if you change identity plug-in servers with user information that is not identical.
If you have sources using the ACL policy Oracle Secure Enterprise Search ACL and you decide to use a different identity plug-in server, then you must clear the ACL data before deactivating the original identity plug-in. If the ACL data is not cleared, then the ACL policy configured for that source while connected to the old identity plug-in server is not correctly enforced after connecting to the new identity plug-in server.
The existing ACL data can be cleared using either of these methods:
Before deactivating the identity plug-in, for each source using the ACL policy Oracle Secure Enterprise Search ACL, switch the ACL policy to No ACL. After connecting to the new identity plug-in server, restore the ACL policy to Oracle Secure Enterprise Search ACL and add the ACLs again. This temporarily makes the source public. If this is unacceptable, then use the next option.
Before deactivating the identity plug-in, delete each source that uses the ACL policy Oracle Secure Enterprise Search ACL. After connecting to the new identity plug-in server, add the sources back and configure them again. The documents are never made public; but this may involve more work than the previous option.
If you have sources using the ACL policy ACLs Controlled by the Source and you decide to use a different identity plug-in server, then after activating the new identity plug-in server, each source that uses this ACL policy must be re-crawled with the Process All Documents option. This forces the reloading and indexing of all of ACL information for such sources using the new identity plug-in server. Select the Process All Documents option on the Home - Schedules - Edit Schedule page.
Note:
If the ACL data is not cleared before switching identity plug-in servers, then you see a message that some users and groups could not be found by the identity plug-in. Those users and groups are still displayed on the Home - Sources -Authorization page. They can be deleted manually.The Oracle SES front-end interface collects user credentials, which are then validated against the active identity plug-in. In addition to authentication of search users, Oracle SES must also authenticate the crawler when accessing external data repositories. Administrators supply credentials to crawl private content through the following authentication methods:
HTML forms
OracleAS Single Sign-On
Oracle Access Manager (OAM) Single Sign-On
It is the administrator's responsibility to check the authorization policy to ensure that crawled documents are properly protected.
Oracle SES has two types of users:
Administrative User: The administrative user is eqsys. This user is natively defined in Oracle SES. Only this user can use the Oracle SES Administration GUI.
Search Users: Oracle SES lets you register an identity plug-in as an interface to any identity management system. (Oracle SES provides registered identity plug-ins for Oracle Internet Directory and other identity management systems.) The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Use the Global Settings - Identity Management Setup page in the Oracle SES Administration GUI to associate Oracle SES with an identity management system.
Oracle Internet Directory is Oracle's native LDAP v3-compliant directory service. It is part of the Oracle Identity Management infrastructure. It is not included in Oracle SES. Oracle Internet Directory should be version 9.0.4 or 10.1.2 (with the latest patch release applied) for connection with Oracle SES. Oracle Internet Directory is not a part of Oracle SES, and therefore Oracle SES can be linked to any existing or new Oracle Internet Directory.
For the eqsys administrative user, a form login screen is available in the Oracle SES Administration GUI. This is the only way for an administrator to log in to Oracle SES.
For search users, there are three possible front-end authentication interfaces:
HTML form login page. Oracle SES provides an authentication page, and it authenticates against the identity plug-in.
Web Services API. The login and logout Web Services operations authenticate against the identity plug-in.
Single sign-on login screen. This can be made available by front-ending Oracle SES with OracleAS Single Sign-On and Oracle HTTP Server. These are available as part of the Oracle Identity Management infrastructure in OracleAS.
Note that whenever the public host name for the Oracle SES query application is different from the internal host name for Oracle SES, you must add a configuration parameter to search.properties. This is so that Oracle SES redirects the public host name to the internal host name. This situation arises when using a load balancer such as BIG-IP or using OracleAS Single Sign-on.
To add the configuration parameter, open ORACLE_HOME/search/webapp/config/search.properties in a text editor and add the ses.qapp.allowed_redirect_hosts parameter. The format is as shown:
ses.qapp.allowed_redirect_hosts=external_host1[, external_host2,...]
For example, if the internal URL for Oracle SES is ses.example.com:7777 and the external URL for the fronting Oracle HTTP Server (OHS) is ses_ext.example.com:8888, then you must add the following to search.properties:
ses.qapp.allowed_redirect_hosts=ses_ext.example.com
Note:
Only form login or single sign-on login can be used for search users at any point in time. Using single sign-on with the Web Services authentication interface is not supported.
Oracle strongly recommends that you SSL-protect the channel between the Oracle HTTP Server and the Oracle WebLogic server instance for secure content.
Much of the information within an organization is publicly accessible. However, there are other sources that are protected. For example, while a user can search in their own e-mail folders, they should not be able to search anyone else's e-mail. A secure search returns only search results that the user is allowed to view based on access privileges.
Oracle SES can use the following two security modes: OracleAS Single Sign-on (SSO) or non-SSO. This is set on the Global Settings - Query Configuration page:
Require login to search secure content only: anyone can search public content. This is the default. This is also known as secure mode 2.
Require login to search secure and public content. This is also known as secure mode 3.
This is applied to both the default query application and Oracle SES Web services. In mode 3, if a user tries to perform any Web services operation (search or document service) without logging in first, then a SOAP exception is thrown indicating that this secure mode requires login for any operation.
This section describes the authorization methods that Oracle SES supports. The authorization methods prevent search users from accessing documents for which they do not have privileges.
Oracle Secure Enterprise Search offers several options for secure search:
See Also:
The Oracle SES administration tutorial athttp://st-curriculum.oracle.com/tutorial/SESAdminTutorial/index.htm
The User Authorization Cache (UAC) source type can crawl and cache user authorization information such as groups and accessible values of user security attributes. This cached information is used at query time to build a security filter. Querying a local cache is much faster than retrieving the authorization information from external repository and identity systems, and thus it significantly reduces the time to build the security filters for the current user. As a result, users can log in to Oracle SES much more quickly. Moreover, you can set up UAC sources to crawl the user authorization information off line, which reduces the load on target repositories at query time.
You can use UAC for sources that are based on either of the security models supported in Oracle SES:
Identity-based security: UAC is enabled for Oracle Internet Directory, Active Directory, and Lotus Notes.
Attribute-based security: UAC is enabled for Oracle Content Database and Oracle Content Server sources. This type of security is also called the user-defined security model.
The crawler stores the following information in the User Authorization Cache:
User groups: The list of groups that a user belongs to.
User attribute values: The values of a specified list of attributes for particular data sources. The values can be single values or arrays of values.
To create a UAC source for an identity plug-in:
Click the Sources tab.
For Source Type, select User Authorization Cache, then click Create.
The Create User-Defined Source page is displayed.
Configure the UAC source with the parameters described in Table 11-5. Set Retrieve user groups to true.
Create and activate the identity plug-in. Configure the plug-in to use the cache.
For example, set these parameters for an OID plug-in:
Use User Cache: true
User Cache Source Name: Name of the UAC source that caches the user group information.
To create a UAC source for attribute-based security:
Click the Sources tab.
For Source Type, select User Authorization Cache, then click Create.
The Create User-Defined Source page is displayed.
Configure the UAC source with the parameters described in Table 11-5. Be sure to set Source names for which security attributes should be crawled.
Configure the data sources to use cached user authorization information for building security filter by setting appropriate UAC related parameters in the authorization plug-in.
For example, set these parameters for Oracle Content Server source:
Use cached user and role information to authorize results: true
User role data source to cache the filter: Name of the UAC source that caches the user authorization information for this data source.
Table 11-5 User Authorization Cache Parameters
| Parameter | Setting |
|---|---|
|
User search query |
Query expression defining the set of users to be crawled. For example, enter This expression is interpreted by the active identity plug-in. When the active identity plug-in is Oracle Internet Directory or Active Directory, specify the LDAP query to select the set of users to crawl. |
|
User attributes to be synchronized from identity system |
Comma-separated list of user attributes to crawl, such as Not used in this release: Leave blank. |
|
Retrieve user groups |
Enter |
|
Source names for which security attributes should be crawled |
Enter a comma-separated list of source names with security attributes to crawl. For example, |
The Federated User Authorization Cache maintains a single User Authorization Cache (UAC) for use by all Oracle SES instances in a federated environment. Any identity plug-in or authorization plug-in can use a Federated UAC.
Prerequisite
Define one or more UAC sources for an Oracle SES instance in the federated environment, as described in "User Authorization Cache". A local cache created on this system can be accessed as a federated UAC source by any other instance with an identically configured identity or authorization plug-in.
To create a federated UAC:
Click the Sources tab.
For Source Type, select Federated UAC, then click Create.
The Create Federated UAC page is displayed.
Configure the federated UAC source with the parameters described in Table 11-6.
Configure an identity or authorization plug-in:
Select the Global Settings secondary tab.
Under System, choose Identity Management Setup.
Activate an identity or authorization plug-in. Enter the name of the federated UAC as the value of the User Cache Source Name parameter.
Repeat these steps for each additional Oracle SES instance in the federated environment.
Table 11-6 Federated UAC Parameters
| Parameter | Setting |
|---|---|
|
Connection String |
JDBC connection string to a remote Oracle SES instance with one or more UAC sources. (Required) |
|
Remote Cache Config File |
Full path name of the XML configuration file for the remote cache, as described in Example 11-1. (Required) |
|
Password |
Password for the eqsys user on the Oracle SES instance identified by Connection String. (Required) |
You can create the remote cache configuration file anywhere on the computer where you defined a federated UAC. You identify the location of the file when defining a Federated UAC source. The file provides details about the remote UAC source. Example 11-1 shows a sample file.
Example 11-1 Remote Cache Configuration File
<?xml version="1.0" encoding="UTF-8"?>
<FederatedUAC>
<UserCache>
<Name>UAC1</Name>
</UserCache>
<UserCache>
<Name>UAC2</Name>
<UserRouting>u6-u10</UserRouting>
</UserCache>
<UserCache>
<Name>UAC3</Name>
<SourceMapping>
<RemoteSourceName>S5</RemoteSourceName>
<LocalSourceName>S1</LocalSourceName>
</SourceMapping>
<SourceMapping>
<RemoteSourceName>S7</RemoteSourceName>
<LocalSourceName>S3</LocalSourceName>
</SourceMapping>
</UserCache>
</FederatedUAC>
Name
The name of a UAC source in a remote instance of Oracle SES from which the federated UAC retrieves user and attribute information. (Required)
UserRouting
Not supported in this release.
SourceMapping
Maps the local source to a remote source with an identically configured authorization plug-in. (Required for attribute-based security)
Use these elements to provide the mapping information:
RemoteSourceName: Name of a remote source defined with a UAC and an authorization plug-in that is configured identically to the plug-in for LocalSourceName. (Required)
LocalSourceName: Name of the local source defined with a federated UAC and an authorization plug-in. (Required)
The following is the XML schema definition for remote cache configuration files:
<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org" attributeFormDefault="unqualified">
<xsd:element name="FederatedUAC">
<xsd:annotation>
<xsd:documentation>Federated Source Configuration</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:all>
<xsd:element name="UserCache">
<xsd:annotation>
<xsd:documentation>
Remote UAC Source Config Details
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:all>
<xsd:element name="Name" minOccurs="1">
<xsd:annotation>
<xsd:documentation>
UAC source name in remote instance from which
user/attribute information must be retrieved
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="UserRouting" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Which users should be routed to this UAC cache. Used for
identity-based security model.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="SourceMapping" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
To map data source prefix for user-defined security
attribute retrieval. This will be used in case of user
defined security model. The mapping information must be
mentioned in the form of remote and local data source names.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:all>
<xsd:element name="RemoteSourceName" maxOccurs="1" minOccurs="1">
<xsd:annotation>
<xsd:documentation>
Remote Instance Data source name prefixed to the
attribute while caching security attribute information
</xsd:documentation>
</xsd:annotation>
<xsd:complexType/>
</xsd:element>
<xsd:element name="LocalSourceName" minOccurs="1">
<xsd:annotation>
<xsd:documentation>
Local Instance Data source name for which security
attribute is being retrieved
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:schema>
With administrator-based authorization, the administrator can specify an authorization policy when creating a source. This policy governs which users can view each document. Administrator-based authorization is based on ACLs. When a source is crawled, each document is stamped with an ACL. When a user enters a search, the result list only includes documents for which the user credentials match the document ACL.
See Also:
"Authentication and Authorization" for more information about ACL policiesOracle SES performs ACL duplicate detection. If a crawled document's ACL exists in the Oracle SES system, then that ACL is used to protect the document, instead of creating a new ACL within Oracle SES. This policy reduces storage space and increases performance.
Oracle SES supports only a single LDAP domain. The LDAP users and groups specified in the ACL must belong to the same LDAP domain.
Caution:
If ACLs are crawled from sources, then ensure that the sources being crawled belong to the same LDAP domain. Otherwise, the end users might inadvertently be granted permission to documents that they should not be able to access.When secure search is enabled, you may encounter up to a 15 minute delay viewing the private documents. This delay could be due to newly added secure sources or a user/group membership change in the identity management system.
Oracle Secure Enterprise Search provides an API for writing custom crawler plug-ins (or connectors) in Java. With this API, you can create a secure crawler plug-in to meet your requirements.
The custom crawler plug-in passes back URLs directly to be indexed. Each URL can be accompanied by an ACL, which restricts the access to that particular document. Alternatively, an ACL can be set in the Oracle SES Administration GUI for the source.
Authentication credentials can be provided to the plug-in through parameters in the Oracle SES Administration GUI. The plug-in uses these credentials to access the secure source.
Within the Crawler Plug-in API, the DocumentAcl object implements identity-based security. Identity-based security is a security policy based on users and groups that is defined by the active identity plug-in.
See Also:
"Crawler Plug-in API"You can do identity-based secure search with administrator-based authorization or custom crawler plug-ins.
Oracle SES provides identity plug-ins for OpenLDAP release 2.2 and 2.3 and Sun Java System Directory Server release 5.1 and 5.2. Activate either of these identity plug-ins on the Global Settings - Identity Management Setup page.
To use administrator-based authorization:
On the Home - Sources page, select a source to use administrator-based authorization.
On the Home - Sources - Customize Source page, click the Authorization tab.
Under Crawl-time ACL Stamping, select Oracle Secure Enterprise Search ACL.
For Type, select User or Group.
Click Add Another Row.
For User, select USER_NAME or something you want to use as Format and enter user name as Name. For Group, select DN as Format and input cn=<Group>,<Group search bases> as Name.
Click Apply.
To use custom crawler plug-ins:
Create a custom crawler plug-in with the Crawler Plug-in API. See "Crawler Plug-in API".
For User & Group, add the following line:
DocumentAcl acl;
// For User
acl.addPrincipal("<User>", DocumentAcl.SIMPLE, DocumentAcl.USER);
// For Group
acl.addPrincipal("cn=<Group>,<Group search bases>", DocumentAcl.DN, DocumentAcl.GROUP);
If you get an error registering the identity plug-in, check the WebLogic log files at ORACLE_HOME/search/base_domain/servers/AdminServers/logs/.
For more detailed information, turn on debug mode and try again to register the identity plug-in. See "Turning On Debug Mode".
Limitations with OpenLDAP and Sun Java System Directory Identity Plug-ins
The LDAP entry of users and groups on OpenLDAP or Sun Java System Directory Server requires the following conditions:
Users:
Belong to the following objectClasses: person, organizationalPerson, and inetOrgPerson
Have the following attributes: dn, cn, sn
The entry's location: uid=<User>,<User search bases>
Groups:
Belong to one objectClasse: groupOfUniqueNames
Have the following attributes: dn, uniqueMember
The entry's location: cn=<Group>,<Group search bases>
Query-time authorization provides another form of filtering. Query-time authorization can be enabled or disabled for Web, file, table, e-mail, mailing list, OracleAS Portal, and user-defined source types from the Home - Sources - Edit Source page. It is not available for federated or self-service sources. Query-time authorization can be used with or without ACLs. For example, a source could be stamped with a relatively broad ACL, while query-time authorization could be used to further filter the results.
In query-time authorization, the Oracle SES administrator associates a Java class that is called at run time. The Java class validates each document that is returned in a user query.
Query-time authorization requires these steps:
The Oracle SES administrator registers a Java class implementing the ResultFilterPlugin interface with a source that requires query-time authorization.
Oracle SES crawls, collects, and indexes all documents. If ACL stamping has been set up, then it ACL stamps the documents.
At search time, the search result list initially contains all documents accessible under crawl-time ACL policies, unfiltered by query-time user privilege checking.
For the top-N results requested by the user, Oracle SES calls the registered Java class, passing in the search request and document information for any documents belonging to the protected source. The Java class returns an integer value for each document indicating if the document should be removed from the result or not.
Only items the user is privileged to see are returned to the user in their result list.
Notes for Using Query-time Authorization:
The Browse application is also filtered by the query-time authorization mechanism. The ResultFilterPlugin class controls which folders are visible to the user, and documents within folders are filtered by the same process as the standard search result list.
Set the Hit Count Method to Exact count (adjusted for query-time filtering) on the Global Settings - Query Configuration page. If it is not set to Exact Count, then the hit count displayed could be larger than the actual number of documents the user is authorized to view. The page in the Oracle SES Administration GUI contains other query-time authorization configuration settings you might want to consider.
Oracle SES reports an approximate count of search results. The number of documents Oracle SES fetches determines the accuracy of the estimation. When the hit count is high enough to go beyond one page of results, then the count changes to a more accurate count as you click Next pages. Exact count shows an accurate count, but this option impacts query response time.
Note:
While crawling secure data sources, the crawler skips infosource count-hit. Changing the ACL policy for a data source from secure to public does not result in an automatic update of the infosource count-hit. If you wish to include the data source in the infosource count-hit, you must recrawl the data source or trigger infosourceupdate_doc_count for the data source.If you modify the contents of the jar file containing the ResultFilterPlugin implementation classes, but do not change the location of the jar file, then you must restart the Oracle SES middle tier. This ensures that the search application picks up your changes and that the Java Virtual Machine does not use a cached version of the class within the old jar file. Restart the middle tier with searchctl restart.
If a ResultFilterPlugin class is enabled for an OracleAS Portal server, then all of its page group sources are automatically protected by that query-time filter.
It may take up to five seconds for query-time authorization changes applied in the Oracle SES Administration GUI to take effect in the Oracle SES search engine. The relevant settings are the following:
Enabling a ResultFilterPlugin class for a source
The hit count method
The Query-time Authorization Configuration settings on the Global Settings - Query Configuration page.
See Also:
"Query-time Authorization API" for more information about implementing aResultFilterPlugin Java classSelf service authorization allows end users to enter their credentials needed to access an external content repository. Oracle Secure Enterprise Search crawls and indexes the repository using these credentials to authenticate as the end user. Only the self service user is authorized to see these documents in their search results. Self service authorization works well out of the box, as the crawler appears to be a normally authenticated end user to the content repository.
To set up a self service source, create a template source, defining the target data repository but omitting the credentials needed to crawl. From the search application, an end user can view the Customize page and subscribe to a template source by entering their credentials in an input form. A new user-subscribed source is created, along with a copy of the template's schedule. Oracle SES creates an ACL for this user to be applied to the source.
User-subscribed sources are viewable in the Home - Sources - Manage Template Source page, and the associated schedules are administered in the Home - Schedules page. Any changes applied by the administrator to a template source are dynamically inherited by the associated user-subscribed sources for the next crawl.
The self service option is available for e-mail and Web sources. Self service e-mail sources require the administrator to specify the IMAP server address and the end user to specify the IMAP account user name and password. Self service Web sources are limited to content repositories that use OracleAS Single Sign-On authentication. The administrator specifies the seed URLs, boundary rules, document types, attribute mappings, and crawling parameters, and the end user specifies the single sign-on user name and password.
Crawling of user-subscribed sources is controlled by the administrator. End users do not see any search results for their subscribed source until that source is crawled by the administrator's schedule. Allowing a crawl to automatically launch immediately after an end user subscribes to a source might be useful. However, it makes it possible for users to load the system at inconvenient times.
If you use OracleAS Single Sign-On (SSO), then you can configure Oracle SES to use your SSO server for authentication. This section describes the necessary configuration steps.
OracleAS supported version with the current Oracle SES installation is 10.1.4.0.1, with the latest patch sets applied. The supported Oracle HTTP Server versions are 10.1.3 and 11g.
Note:
ORACLEAS_HOME refers to the Oracle home directory of the OracleAS middle tier installation, which is typically stored in a system variable. On UNIX systems, you can reference the path as $AS_HOME. On Windows, the equivalent is %AS_HOME%.
ORACLEOHS_HOME refers to the home directory of the Oracle HTTP server installation.
To enable Oracle SES for OracleAS Single Sign-on:
Front the Oracle SES instance with Oracle HTTP Server, as described in "Configuring Oracle HTTP Server".
Configure OracleAS and Oracle SES, as described in "Configuring OracleAS and Oracle SES for Single Sign-on Security".
The Oracle SES middle tier runs on Oracle WebLogic server, which is installed in ORACLE_BASE/wlserver.
You can configure either Oracle HTTP Server 10.1.3 or Oracle HTTP Server 11g. Special configuration is necessary on both the Oracle SES side and the Oracle HTTP Server side.
Note:
When using Oracle HTTP Server fronting, Oracle SES allows the Oracle HTTP Server to assert the identity of the current user. You must limit this privilege to only trusted Oracle HTTP Server instances by SSL-protecting the communication between Oracle SES and Oracle HTTP Server.To configure Oracle HTTP Server 10.1.3:
Copy the file mod_wl_20.so from ORACLE_BASE/wlserver/server/plugin/linux/i686 to ORACLEOHS_HOME/ohs/modules.
Edit the file httpd.conf available at ORACLEOHS_HOME/ohs/conf/ to include the following lines:
LoadModule weblogic_module [Complete path to mod_wl_20.so] <IfModule mod_weblogic.c> WebLogicHost [SES host name] WebLogicPort [SES HTTP port] </IfModule> <Location /search/query> SetHandler weblogic-handler </Location> <Location /search/admin> SetHandler weblogic-handler </Location>
For example, if the ORACLEOHS_HOME is /ohsHome, Oracle SES host is sesHost and the Oracle SES port is 8001, then the file contains the following content:
LoadModule weblogic_module /ohsHome/ohs/modules/mod_wl_20.so <IfModule mod_weblogic.c> WebLogicHost sesHost WebLogicPort 8001 </IfModule> <Location /search/query> SetHandler weblogic-handler </Location> <Location /search/admin> SetHandler weblogic-handler </Location>
Edit the httpd.conf to comment out or remove the following lines:
#LoadModule auth_module modules/mod_auth.so #LoadModule auth_anon_module modules/mod_auth_anon.so #LoadModule auth_db_module modules/mod_auth_dbm.so
Register Oracle HTTP Server mod_osso with Oracle Single Sign-On server 10.1.4. To do this, run the following command from ORACLEAS_HOME:
>setenv ORACLE_HOME [full path to $OracleAS_Home] >$OracleAS_Home/sso/bin/ssoreg.sh –oracle_home_path [Complete Path of OracleAS_Home] -site_name [Hostname Of The Fronting OHS Server:Port] -config_mod_osso TRUE -mod_osso_url [http:// Hostname Of The Fronting OHS Server:Port] -update_mode CREATE -remote_midtier -config_file [Path to generate the file osso.conf]
For example, if you installed Oracle Identity Management 10g in /asHome, and the OHS URL is http://ohsserver:7779, then you must run the following command:
>setenv ORACLE_HOME /asHome >$OracleAS_Home/sso/bin./ssoreg.sh -oracle_home_path /asHome -site_name ohsserver:7779 -config_mod_osso TRUE -mod_osso_url http://ohsserver:7779 -update_mode CREATE -remote_midtier -config_file /temp/osso.conf
Configure mod_osso to protect web resources with static directives. To do this, perform the following steps:
Copy the file osso.conf generated in step 4 to: ORACLEOHS_HOME/ohs/conf/osso.
Edit the file mod_osso.conf available at ORACLEOHS_HOME/ohs/conf/ to include the following:
LoadModule osso_module [path of OracleOHS_Home]/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile [path of OracleOHS_Home]/ohs/conf/osso/osso.conf
#OssoRedirectByForm off
#OssoSecureCookies on
#OssoProtectedOnly on
#OssoSecureCookies on
#OssoSendCacheHeaders on
#OssoHttpsFrontend on
#UseWebCacheIp on
<Location /search/query/formlogin.uix>
require valid-user
AuthType Basic
</Location>
</IfModule>
Edit the file httpd.conf to include the following:
include OracleOHS_Home/ohs/conf/mod_osso.conf
For example, if your ORACLEOHS_HOME is /ohsHome, then the value would be:
include /ohsHome/ohs/conf/mod_osso.conf
Restart the HTTP server. To do this, run the following:
> $OracleOHS_Home/opmn/bin/opmnctl restartproc process-type=HTTP_Server
To configure Oracle HTTP Server 11g:
Set ORACLE_HOME and ORACLE_INSTANCE.
For example, if Oracle HTTP Server is installed at /ohsHome:
>setenv ORACLE_HOME /ohsHome
If the instance is named myInstance
>setenv ORACLE_INSTANCE /ohsHome/instances/myInstance
Edit the file mod_wl_ohs.conf available at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/ to include the following:
<IfModule weblogic_module> WebLogicHost [SES host name] WebLogicPort [SES HTTP port] Debug ON WLLogFile Convenient Location of the log </IfModule> <Location /search/query> SetHandler weblogic-handler </Location> <Location /search/admin> SetHandler weblogic-handler </Location> # For monitor SES URL <Location /monitor> SetHandler weblogic-handler </Location> # For Help links in Admin side <Location /search/ohw> SetHandler weblogic-handler </Location>
For example, if your Oracle SES host is sesHost and Oracle SES port is 8001,
<IfModule weblogic_module> WebLogicHost sesHost WebLogicPort 8001 WLLogFile /scratch/exampleuser/weblogic.log </IfModule> <Location /search/query> SetHandler weblogic-handler </Location> <Location /search/admin> SetHandler weblogic-handler </Location> <Location /monitor> SetHandler weblogic-handler </Location> <Location /search/ohw> SetHandler weblogic-handler </Location>
Register Oracle HTTP Server mod_osso with Oracle Single Sign-On Server 10.1.4. To do this, run the following command from ORACLEAS_HOME:
>setenv ORACLE_HOME [full path to $OracleAS_Home] >$OracleAS_Home/sso/bin/ssoreg.sh –oracle_home_path [Complete Path of OracleAS_Home] -site_name [Hostname Of The Fronting OHS Server:Port] -config_mod_osso TRUE -mod_osso_url [http:// Hostname Of The Fronting OHS Server:Port] -update_mode CREATE -remote_midtier -config_file [Path to generate the file osso.conf]
For example, if you installed Oracle Identity Management 10g in /asHome, and the OHS URL is http://ohsserver:7779, then you need to run the following command:
>setenv ORACLE_HOME /asHome >$OracleAS_Home/sso/bin./ssoreg.sh -oracle_home_path /asHome -site_name ohsserver:7779 -config_mod_osso TRUE -mod_osso_url http://ohsserver:7779 -update_mode CREATE -remote_midtier -config_file /temp/osso.conf
Configure mod_osso to protect Web resources with static directives. To do this, perform the following:
Copy osso.conf generated above to the location OracleOHS_HOME/instances/instance1/config/OHS/ohs1/conf
Copy the file mod_osso.conf from ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/disabled/ to OracleOHS_HOME/instances/instance1/config/OHS/ohs1/moduleconf/.
Edit the file mod_osso.conf located at OracleOHS_HOME/instances/instance1/config/OHS/ohs1/moduleconf to include the following lines:
LoadModule osso_module ${OracleOHS_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoSecureCookies Off
OssoConfigFile <path_to_osso.conf_file>
#Location is the URI you want to protect
<Location />
require valid-user
AuthType Osso
</Location>
</IfModule>
For example if your OracleOHS_Home is /ohsHome and you generated the osso.conf file at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/conf, then you need to include the following:
LoadModule osso_module "${OracleOHS_HOME}/ohs/modules/mod_osso.so"
<IfModule osso_module>
OssoIpCheck off
OssoIdleTimeout on
OssoSecureCookies Off
OssoConfigFile /ohsHome/instances/instance1/config/OHS/ohs1/conf/osso.conf
<Location /search/query/formlogin.uix>
require valid-user
AuthType Osso
</Location>
</IfModule>
Edit the file httpd.conf located at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/ to include the following at the end of the file:
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/moduleconf/mod_osso.conf"
# Include the configuration files needed for mod_weblogic
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/mod_wl_ohs.conf"
# Include the SSL definitions and Virtual Host container
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/ssl.conf"
# Include the admin virtual host (Proxy Virtual Host) related configuration
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/admin.conf"
include "moduleconf/*.conf"
Restart the HTTP server with the command
/$OracleOHS_Home/instances/instance1/bin/opmnctl startproc process-type=OHS
To configure OracleAS to front Oracle SES:
Add providers for a WebLogic domain for OSSO. To do this, copy the file ossoiap.jar to the following location within Oracle WebLogic Server: ORACLE_BASE/wlserver/server/lib/mbeantypes/ . The file ossoiap.jar is located in ORACLEOHS_HOME/modules/oracle.ossoiap_11.1.1/.
Note that ossoiap.jar is available only with OHS 11g. If you have configured SSO with OHS 10g, then you must separately install OHS 11g to obtain this file.
Restart the Oracle SES midtier.
searchctl restart
Add OSSO Identity Asserter as described in "Adding OSSO Identity Asserter".
Add OID Authenticator as described in "Adding OID Authenticator".
Turn on the Single Sign-On flag in Oracle SES. This is done by updating the deployment plan for the query application. To do this:
Edit the file QueryPlan.xml located in ORACLE_HOME/search/tools/weblogic/deploy/plans/ to add the following:
<variable-definition> <variable> <name>sso_enabled</name> <value>true</value> </variable> <variable> <name>sso_vendor_name</name> <value>osso</value> </variable> <variable> <name>sso_user_guid_header</name> <value>Osso-User-Guid</value> </variable> <variable> <name>sso_username_header</name> <value>REMOTE_USER</value> </variable> </variable-definition>
Redeploy the query application with the modified deployment plan. To do this, run the following command from ORACLE_HOME/search/tools/weblogic/deploy/
>./deployer.sh -serverURL t3://<URL of the weblogic server>:<port> -user Weblogic Username -password SES Admin Password -name Name of the app -plan Location of the deployment plan -process <redeploy or deploy>
For example, if you install Oracle SES on the host myWlsServer and port 6666, and the Oracle SES admin password is welcome1, then you need to issue the following command:
> ./deployer.sh -serverURL t3://myWlsServer:6666/ -user weblogic -password welcome1 -name search_query -plan $ORACLE_HOME/search/tools/weblogic/deploy/plans/QueryPlan.xml -process redeploy
To add an OSSO Identity Asserter to the domain, use the Oracle WebLogic Administration Console to perform the following steps:
Log in to the WebLogic Administration Console.
Click Security Realms, Default Realm Name, Providers.
Click New under the Authentication Providers table.
Enter a name for the new provider, select its type, and then click OK. For example:
Name: OSSO Identity Asserter
Type: OSSOIdentityAsserter
Click the name of the newly added provider.
On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.
Save all configuration settings.
Stop and restart the Oracle WebLogic Server for the changes to take effect.
To add an OID Authenticator to the domain, use the Oracle WebLogic Administration Console to perform the following steps:
Log in to the WebLogic Administration Console.
Click Security Realms, Default Realm Name, Providers.
Click New under the Authentication Providers table.
Enter a name for the new provider, select its type, and then click OK. For example:
Name: OID Authenticator
Type: OracleInternetDirectoryAuthenticator
Click Save.
Click the newly added authenticator to see the Settings page. Retain the default settings; do not change the Control Flag until you have verified that the Oracle Internet Directory configuration is valid.
On the Common tab, specify the following required settings and then save the settings.
Propagate Cause For Login Exception: Check.
Principal: LDAP administrative user. For example: cn=orcladmin
Host: The Oracle Internet Directory host name
Use Retrieved User Name as Principal: Check
Credential: LDAP administrative user password. For example: password
Confirm Credential: For example: password
Group Base DN: Oracle Internet Directory group search base
User Base DN: Oracle Internet Directory user search base.
Port: Oracle Internet Directory port
Save all configuration settings.
Stop and restart the Oracle WebLogic Server for the changes to take effect.
After adding OSSO Identity Asserter and OID Authenticator as authentication providers, perform the following steps:
Log in to the WebLogic Administration Console.
Click Security Realms, Default Realm Name, Providers.
Select the Users and Groups tab to see a list of users and groups contained in the configured authentication providers.
You should see user names from the Oracle Internet Directory configuration, which implicitly verifies that the configuration is working.
If the Oracle Internet Directory instance is configured successfully, you can change the control flag.
If the Oracle Internet Directory authentication is sufficient for an application to identify the user, then choose the SUFFICIENT flag. SUFFICIENT indicates that if a user can be authenticated against Oracle Internet Directory, no further authentication is required. REQUIRED indicates that the authentication provider must authenticate the user even if another provider has already authenticated the user.
If your application requires the user name to be in the same case as in Oracle Internet Directory (uppercase, lowercase, initial capitals), select Use Retrieved User Name as Principal.
Save the changes.
Activate the changes and restart Oracle WebLogic Server.
You can implement an SSO authentication mechanism for Oracle SES by using OAM.
Ensure that the following components are installed:
OAM 10.1.4.3.0. See Oracle Access Manager Installation Guide.
Oracle HTTP Server (OHS) 11g.
Oracle Internet Directory (OID) 10.1.4.3.0 or higher. See Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. Also see "Configuring OID" for information on configuring OID.
Oracle HTTP Server WebGate.
Note that you must install OAM, and then add an entry for WebGate in OAM prior to installing WebGate. Oracle Access Manager Installation Guide provides detailed information about installing WebGate. Follow the steps as provided in this guide. However, for some of the steps, such as while creating a WebGate instance and while installing the WebGate, you must provide certain OAM SSO-specific parameters, as listed in "Installing and Configuring WebGate".
To implement the OAM-SSO authentication on Oracle SES, you must configure OHS, Oracle SES, OID, and OAM.
You must install OID 10.1.4.3.0 or higher. This is required because the Oracle SES parameter sso_user_guid_header must be used to send the ORCLGUID attribute from OAM to SES, and this can be done only with OID 10.1.4.3.0 or higher.
To enable this on OID:
Add the following to the LDIF file:
dn: cn=dsaconfig, cn=configsets,cn=oracle internet directory changetype: modify add: orclallattrstodn orclallattrstodn: cn=orcladmin
Import the LDIF file into OID. To do this, use the following command:
$LDAP_HOME/bin/ldapmodify -D cn=orcladmin -w <password> -h <host> -p <port> -c -v -f <ldifFile>
To verify that the changes you made to the LDIF file are reflected, use the following command:
$LDAP_HOME/bin/ldapsearch -b "cn=dsaconfig,cn=configsets,cn=oracle internet directory" -s base -h <host> -p <port> -w <password> -D "cn=orcladmin" "objectclass=*"
You should see orclallattrstodn as an attribute of the dsaconfig entry.
Restart the OAM Access Server and the OAM Identity Server:
$OAM_HOME/as/access/oblix/apps/common/bin/restart_access_server $OAM_HOME/is/identity/oblix/apps/common/bin/restart_ois_server
To configure OHS, perform the following tasks:
Edit mod_wl_ohs.conf to include the following. The file is available at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/, where instance1 refers to the instance name of OHS.
<IfModule weblogic_module>
WebLogicHost [SES host name]
WebLogicPort [SES HTTP port]
WLLogFile Convenient Location of the log
</IfModule>
<Location /search/query>
SetHandler weblogic-handler
</Location>
<Location /search/admin>
SetHandler weblogic-handler
</Location>
# For monitor SES URL
<Location /monitor>
SetHandler weblogic-handler
</Location>
# For Help links in Admin side
<Location /search/ohw>
SetHandler weblogic-handler
</Location>
For example, if your SES host is sesHost and the port is 8001:
<IfModule weblogic_module>
WebLogicHost sesHost
WebLogicPort 8001
WLLogFile /scratch/exampleuser/weblogic.log
</IfModule>
<Location /search/query>
SetHandler weblogic-handler
</Location>
<Location /search/admin>
SetHandler weblogic-handler
</Location>
<Location /monitor>
SetHandler weblogic-handler
</Location>
<Location /search/ohw>
SetHandler weblogic-handler
</Location>
Edit httpd.conf located at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/ to include the following at the end of the file:
# Include configuration for mod_weblogic
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/mod_wl_ohs.conf"
Ensure that this line of code is on a single line.
Restart the HTTP server.
$ORACLEOHS_HOME/instances/instance1/bin/opmnctl restartproc process-type=OHS
A WebGate is a Web server plug-in that is shipped out-of-the-box with Oracle Access Manager. The WebGate intercepts HTTP requests from users for Web resources and forwards them to the Access Server for authentication and authorization. See Oracle Access Manager Installation Guide for more information on installing a WebGate.
While installing WebGate, you must configure some parameters for the OAM SSO authentication.
Provide the following values while defining a WebGate instance in the Access System Console:
AccessGateName: Set as SESAccessGate
Description: Set as Secure Enterprise Search Access Gate
HostName: This is the host name on which OHS is installed.
AccessGate Password: Set a password.
Port: This is the port number set during OHS installation.
Transport Security: Set to Open.
Preferred HTTP Host: The domain for OHS. For example, if the OHS hostname is myhost.oracle.com, then the domain is oracle.com.
Ensure that Access Management Service is on.
Provide the following parameters while specifying the WebGate configuration details:
WebGate ID: Enter SESAccessGate.
WebGate Password: The same as AccessGate password.
Access Server ID: Obtain this from Access System Console.
DNS hostname: Obtain this from Access System Console.
Port number: Obtain this from Access System Console.
Perform the following tasks:
Create a login page for Oracle HTTP Server. For example, ORACLEOHS_HOME/ohs/htdocs/login/login.html:
<html>
<head>
<title>SES-OAM Test Login Page</title>
<body bgcolor="white">
<h1 align="center">SES-OAM SSO Login Page: Sign-In</h1>
<form method="POST" action="/myaction/test.html">
<table border="0" cellspacing="5">
<tr>
<th align="right">Username:</th>
<td align="left"><input type="text" name="usernamevar"></td>
</tr>
<tr>
<th align="right">Password:</th>
<td align="left"><input type="password" name="passwordvar"></td>
</tr>
<tr>
<td align="right"><input type="submit" value="Log In"></td>
<td align="left"><input type="reset"></td>
</tr>
</table>
</form>
</html>
Define a form-based authentication in OAM Policy Manager:
From http://OAMHost:OAMPort/access/oblix, select Access System Console, then Access System Configuration, and then Authentication Management.
Create Form Login method with the following options:
Name: OAMFormLogin
Description: OAM Form-based login
Level: 1
Challenge Method: Form
Challenge Parameter
form: /login/login.html
creds: usernamevar passwordvar
action: /myaction/test.html
passthrough: no
SSL Required: No
Enabled: Yes
Set up the following plugins under the Plugins tab:
credential_mapping:
obMappingBase="o=company,c=us",obMappingFilter="(&(&(objectclass=gensiteorgperson)(genuserid=%usernamevar%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))"
validate_password:
obCredentialPassword="passwordvar"
where obMappingBase is the base DN in the user search in the LDAP directory server, and obMappingFilter is the LDAP filter used to search for a user with a given userID. The directory login attribute is an attribute defined in the Identity System using a Semantic login type.
Ensure that a default step exists in the Steps tab to use the credential_mapping and validate_password plugins.
Create a policy in the Policy Manager to protect the query application login link using the form authentication created in the previous step. To do this,
From http://OAMHost:OAMPort/access/oblix, select Policy Manager, and then Create Policy Domain.
Protect an HTTP resource with /search/query/formlogin.uix as the URL prefix.
In the Authorization Rules tab, add the role myrole. Also set the following:
Enabled: Yes
Allow takes precedence: Yes
Under Actions tab for myrole, first add the following return action:
Type: HeaderVar
Name: HTTP_USER_GUID
Return Attribute: orclguid
Then add the following return action:
Type: HeaderVar
Name: HTTP_USER_NAME
Return Attribute: uid
Under Allow Access tab, ensure that anyone is allowed access.
Enable the new policy under My Policy Domains.
Click Default Rules, and under Authentication Rule, add a rule to use the form login scheme as the Authentication Scheme.
Under Authorization Expression, ensure that myrole is selected for Default Rules.
Create a policy in Policy Manager to protect the HTTP resource /search/query with the Anonymous Authentication option. Note that the steps are identical to the previous step. However, for step 3g, the form login scheme must be Anonymous Authentication under Authentication Rule.
Configure Oracle SES to use HTTP_USER_GUID and HTTP_USER_NAME as the values of sso_user_guid_header and sso_username_header respectively. See "Configuring QueryPlan.xml in Oracle SES".
Configure Oracle SES to use OblixAnonymous as the value for sso_public_username. See "Configuring QueryPlan.xml in Oracle SES".
To enable OAM SSO authentication, you must configure the following parameters in the QueryPlan.xml file, which is available at ORACLE_HOME/search/tools/weblogic/deploy/plans/.
<variable> <name>sso_enabled</name> <value>true</value> <description>Whether SSO is enabled: true or false. The default is false. </description> </variable> <variable> <name>sso_vendor_name</name> <value>oam</value> <description>The SSO vendor name. Supported values are osso or oam.</description> </variable> <variable> <name>sso_user_guid_header</name> <value>HTTP_USER_GUID</value> <description>The HTTP header name that the SSO server uses to pass the user GUID to SES. The value in the header should match the value of the users canonical attribute for the active identity plugin.</description> </variable> <variable> <name>sso_username_header</name> <value>HTTP_USER_NAME</value> <description>The HTTP header name that the SSO server uses to pass the search username to SES. The value in the header should match the value of the users authentication attribute for the active identity plugin. Specify REMOTE_USER to use getRemoteUser in the HTTP request to retrieve the username.</description> </variable> <variable> <name>sso_public_username</name> <value>OblixAnonymous</value> <description>(Optional) Specify the username of the public user if the SSO server is configured to send a public user name in the sso_username_header for unprotected or anonymously protected resources.</description> </variable>
For SSL support, Oracle SES uses JSSE, a highly-customizable SSL package included in Sun Microsystem's J2SE. Oracle SES uses SSL for many operations, some acting as the SSL client, and others acting as the SSL server.
Oracle SES can crawl HTTPS-based URLs, and the Oracle SES middle tier can be configured to support HTTPS-based access. HTTPS refers to HTTP running over a secure socket layer (SSL).
SSL is an encryption protocol for securely transmitting private content on the internet. Using SSL, two parties can establish a secure data channel. SSL uses a cryptographic system that uses two keys to encrypt data: a public key and a private key. Data encrypted with the public key can only be decrypted using the private key, and vice versa.
In SSL terms, the party that initiates the communication is considered the client. During the SSL handshake, authentication between the two parties occurs. The authentication can be one sided (server authentication only) or two sided (server and client authentication).
Server authentication is more common. It happens every time a Web browser accesses a URL that starts with HTTPS. Because of server authentication, the client can be certain of the server's identity and can trust that it is safe to submit secure data such as login username and password to the server.
The following list defines some common terms related to SSL:
Keystore: A repository that includes the following:
Certificates identifying trusted entities. If a keystore contains certificates of only trusted entities, then it is referred to as a truststore.
Private-key and the matching certificate. This certificate is sent as a response to SSL authentication challenges.
Certificate: A digital identification of an entity that contains the following:
SSL public key of the server
Information about the server
Expiration date
Digital signature by the issuer of the certificate used to verify the authenticity of the certificate
Certificate authority (CA): A well known and trusted entity (for example, VeriSign or Thawte). CAs are usually the issuers of other certificates.
Root certificate: A self-signed certificate where the issuer is the entity that the certificate represents. CA certificates are typically root certificates.
Certificate chain: This chain consists of the certificate, its issuer, the issuer of the issuer, and so on, all the way to the root certificate. If one certificate in the chain is trusted (that is, it is in the keystore), then the rest of the certificate can be verified for authenticity. This makes it possible for a keystore to contain only a few well-known and trusted root certificates from which most other certificates originate.
Every SSL connection starts with the SSL handshake. These are the basic steps:
The client contacts the server to establish a SSL connection.
The server looks in its keystore for its own SSL certificate and sends it back to the client.
The client checks its keystore to see if it trusts the server or any of the entities in the server's certificate chain. If not, then the handshake is aborted. Otherwise, the client positively identifies the server and deems it trusted. The expiration date of the certificate is also checked, and the name on the certificate is matched against the domain name of the server.
If the server is configured to require client authentication, then the server asks the client to identify itself, so the mirror image of steps 2 and 3 takes place.
Session keys are generated and used for encrypting the transmitted data.
Oracle strongly recommends that you use an SSL-protected channel to transmit password and other secure data over networks.
Typically, the following components transmit password and other secure data over a network:
Federation
Connectors
Authorization Plugin
Identity plugin
Suggested content
Web Service APIs
The keystore is populated with the root certificates representing well known certificate authorities. Most SSL-enabled Web sites use certificates that originate or chain from these main root certificates. See "Oracle SES Acting as an SSL Server" for more information about managing the keystore.
See Also:
The Java Secure Socket Extension (JSSE) Reference Guide athttp://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html
Depending on requirements, the keystore might need maintenance. For example:
If a main root certificate has expired, then it must be replaced by a new issue.
If Oracle SES must trust another SSL-enabled peer whose certificate does not originate from a root certificate, then the peer's certificate, or one from its chain, must be added to the keystore.
To enable SSL in the Oracle SES middle tier, Oracle SES must act as an SSL server, and that calls for the keystore to contain a private key and the corresponding certificate with the public key. (The same holds true for the SSL client role where the server requires client side SSL authentication.)
Maintenance of the keystore can be done using Sun Microsystem's keytool program, which ships with J2SE. You can find this utility under ORACLE_HOME/jdk/bin). Third-party keytool GUI wrapper programs are available.
See Also:
For detailed instructions on how to add, remove, or update certificates, generate keys, and create new keystores with a keytool:http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
Oracle SES acts as the SSL client in the following situations:
The crawler accesses a data repository that uses SSL (for example, HTTPS Web sites).
The form registration wizard in the Oracle SES Administration GUI accesses HTTPS URLs.
Oracle SES federates queries to other SSL-enabled search services (for example, an SSL-enabled Oracle SES instance).
Note that for Oracle SES 11.1.2 instances, the broker and the endpoint do not have to exchange any certificates when the broker tries to create a federated source using the HTTPS Web service URL. This is because the Oracle SES instances share the same default certificates in the trusted store.
If you crawl an SSL-enabled Web site whose SSL key is not in the SSL keystore, the following error occurs:
@ javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found
To fix this error, you can add the key to the Oracle SES keystore.
To add an SSL certificate to the Oracle SES keystore:
Access the page in a browser, and accept the SSL certificate when prompted.
View the certificate through your browser options.
Import the certificate into the Oracle SES keystore.
Try the crawl again.
The following sections explain how to import certificates.
Oracle SES acts as the SSL server when the Oracle SES middle tier, configured to use SSL, responds to HTTPS requests. The Oracle SES crawler connects to SSL-enabled sites using the JSSE package, which contains a keystore with a few default certificates from well known CAs.
This section contains the following topics:
When Oracle SES is fronted by an Oracle HTTP Server, Oracle recommends that Oracle SES be configured to require SSL with client-side authentication for communication with the Oracle HTTP Server. Furthermore, a keystore other than the default one should be used. It is highly recommended that you create separate identity and trust keystores.
The communication channel between the client and Oracle SES is by default not SSL-enabled and not encrypted.
Perform the following steps:
Create a new keystore. This step is optional but Oracle recommends it. To do this,
Log in to the admin console for WebLogic available at http://sesHost:sesPort/console. Use the following credentials:
Login Name: weblogic
Password: Oracle SES Administrator's password
Expand the Environment button and click Servers. This takes you to the configuration page for the servers.
Click on the name of the server for which you want to configure SSL.
Click the keystores tab.
From the keystores list, select Custom Identity and Custom Trust.
In the custom identity keystore field add the complete path and name of the new keystore that you want to create.The default keystore is located at ORACLE_BASE/wlserver/server/lib. To create a new keystore SESIdentity.jks, add the path and name ORACLE_BASE/wlserver/server/lib/SESIdentity.jks to the keystore field.
Set the custom identity keystore type to be jks. Set a pass phrase for the store.
In the custom trust field, add the complete path and name of the new keystore that you want to create. The default keystore is located at ORACLE_BASE/wlserver/server/lib. To create a new keystore SESTrust.jks, add the path and name ORACLE_BASE/wlserver/server/lib/SESTrust.jks to the keystore field.
Set the custom identity keystore type to be jks. Set a pass phrase for the store.
Click Save to create the new keystores.
Create new certificates for the identity and trust keystores. To do this, use Sun Microsystem's keytool utility to perform the following steps:
Generate the key for the identity keystore. To do this, run the following command from ORACLE_HOME:
>keytool -genkey -alias [MyCertificateAlias] -keyalg RSA -keysize 1024 -dname ["My DN"] -keypass [MyKeyPass ] –keystore [MyKeyStore ] -storepass [PasswordOfTheKeystoreCreatedAbove] –storetype [StoreTypeCreatedAbove]
For example,
> keytool -genkey -alias sescert -keyalg RSA -keysize 1024 -dname "CN=example0123.us.mycompany.com,OU=ses,O=oracle,C=us" -keypass welcome1 -keystore $ORACLE_BASE/wlserver/server/lib/SESIdentity.jks -storepass welcome1 -storetype jks
The above command creates a certificate with the alias sescert and the given dn and keypass welcome1. It uses SESIdentity.jks as the keystore, which is the same as the one created in step 1. The storepass and the storetype are the same as supplied in step 1.
Generate the key for the trust keystore by running the following command from ORACLE_HOME.
> keytool -genkey -keyalg RSA -alias sescert -keysize 1024 -dname "CN=example0123.us.mycompany.com,OU=ses,O=oracle,C=us" -keypass welcome1 -keystore $ORACLE_BASE/wlserver/server/lib/SESTrust.jks -storepass welcome1 -storetype jks
Certify the generated keys by running the following command from ORACLE_HOME.
> keytool -selfcert -alias sescert -keyalg RSA -validity 2000 -keypass welcome1 –keystore $ORACLE_BASE/wlserver/server/lib/SESIdentity.jks -storepass welcome1
The command uses the alias, keypass, and the keystore location supplied in step 2.a. The store pass is the password of the store.
To self certify the keystore, run the following command from ORACLE_HOME.
> keytool -selfcert -alias sescert -keyalg RSA -validity 2000 -keypass welcome1 -keystore $ORACLE_BASE/wlserver/server/lib/SESTrust.jks -storepass welcome1
Note:
In addition to using Sun Microsystem's Keytool utility to self-sign the generated key, you can use any of the options mentioned here:http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/identity_trust.htmlConfigure Oracle SES to use the generated key. To do this, perform the following steps:
Log in to the admin console for WebLogic and select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. This takes you to the configuration page for the servers.
Click the ssl tab.
The private key location is set to from Custom Identity Keystore.
In the Private Key Alias field, provide the private key alias. This is the alias specified in step 2a.
Provide the private key pass phrase that you specified in step 2a.
Save the settings.
Enable SSL for Oracle SES. To do this, perform the following steps:
Log in to the admin console for WebLogic and select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. This takes you to the configuration page for the servers.
Click the General tab.
Select SSL Listen Port Enabled and provide a port number. The default port is 7002.
Save the settings.
Click the Control tab. You can access the control tab by expanding the Environment button and clicking on Servers.
From the control tab, restart SSL.
Configuring OHS to require SSL is a multistep process involving configuration of the server, modification of certain .conf files, and exchange of certificates.
To configure Oracle HTTP Server to require SSL:
Configure the Oracle HTTP server. To do this, perform the following steps:
From ORACLEOHS_HOME/bin, run owm. This opens Oracle Wallet Manager, which is used to create the certificate for OHS.
Click Wallet and then click New.
If you get a message indicating that the default directory is not set, click Continue.
Provide a password for the wallet. Click No for the option to configure user certificate request.
Click Wallet and then click Save As. Save the wallet to the directory ORACLE_HOME/instances/instanceName/config/OHS/ componentName/keystores/myWallet. This creates a new wallet with the name myWallet for the Oracle HTTP server.
instanceName and componentName are specified during the installation of Oracle HTTP Server.
Create a key-cert pair (a user certificate) using the following command from ORACLEOHS_HOME/bin
> orapki wallet add -wallet [walletPath] -dn ["myDN"] -keysize 1024 -self_signed -validity 720
For example,
> orapki wallet add -wallet $ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/keystores/myWallet –dn CN=example0123.us.mycompany.com,OU=ohs.ses,O=oracle,ST=ca,C=US -keysize 1024 -self_signed -validity 720
The command adds a user certificate with the given dn and the wallet located at ORACLEOHS_HOME/instances/instance1/config/OHS/ohs1/keystores/myWallet. Note that instance1 is the name of the instance provided during installation and ohs1 is the name of the component provided during installation.
Go back to the OWM utility and reopen the wallet. To do this, close and open the wallet by selecting the correct directory. You should now see Certificate:[Ready] under the wallet.
Save the wallet.
Double-click Certificate:[Ready], click the Operations tab, and select export user certificate. Export the user certificate file (/tmp/OHSIdentityCertificate.crt) to a suitable location.
Edit the file ssl.conf located at ORACLEOHS_HOME/instances/instanceName/config/OHS/componentName/.to include the following. Note that instanceName and componentName are specified during the installation of Oracle HTTP Server.
<VirtualHost*:dddd> <IfModule mod_weblogic.c> WebLogicHost [SESHost] WebLogicPort [SESPort] Debug ALL WLLogFile [Location of the log file] SecureProxy On WlSSLWallet “MyWalletLocation” <Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic </Location> <Location /console> SetHandler weblogic-handler </Location> </IfModule> </VirtualHost >
For example, if the host is sesHost, the port is 7002, and the wallet is located at Oracle_Instance/config/Component_Type/Component_Name/keystores/myWallet, then the following configuration file is helpful:
<IfModule mod_weblogic.c>
WebLogicHost sesHost
WebLogicPort 7002
Debug ALL
WLLogFile /scratch/exampleuser/Certificates/weblogic.log
SecureProxy On
WlSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/myWallet"
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
</Location>
<Location /console>
SetHandler weblogic-handler
</Location>
</IfModule>
Edit the file mod_wl_ohs.conf located at ORACLEOHS_HOME/instances/instanceName/config/OHS/componentName/ to include the following:
<IfModule weblogic_module>
WebLogicHost [SES host name]
WebLogicPort [SES HTTP port]
Debug ON
WLLogFile [Location of the log]
</IfModule>
<Location /search/query>
SetHandler weblogic-handler
</Location>
<Location /search/admin>
SetHandler weblogic-handler
</Location>
# For monitor SES URL
<Location /monitor>
SetHandler weblogic-handler
</Location>
# For Help links in Admin side
<Location /search/ohw>
SetHandler weblogic-handler
</Location>
For example if the Oracle SES host is sesHost and the port is 8001, then the file would contain:
<IfModule weblogic_module>
WebLogicHost sesHost
WebLogicPort 8001
Debug ON
WLLogFile /scratch/exampleuser/weblogic.log
</IfModule>
<Location /search/query>
SetHandler weblogic-handler
</Location>
<Location /search/admin>
SetHandler weblogic-handler
</Location>
<Location /monitor>
SetHandler weblogic-handler
</Location>
<Location /search/ohw>
SetHandler weblogic-handler
</Location>
Exchange the certificates for OHS and Oracle SES WebLogic servers. To do this, use Oracle Wallet Manager to import and export certificates from and to the wallet, and use the Java keytool for the Oracle SES keystore. While importing a certificate, ensure that it is self-signed. If not, then you must import any of the certificates in the chain. See "Understanding SSL" for more information about certificate chains.
Perform the following steps to exchange certificates:
Export the SESIdentity key generated in step 2a of Configuring Oracle Secure Enterprise Search to Require SSL to a suitable location by running the following command:
> keytool -export -alias sescert –keystore $ORACLESES_HOME/wls/wlserver/server/lib/SESIdentity.jks -file /tmp/SESIdentityCertificate.crt
The above command exports the certificate with the alias sescert and the keystore created in step 2a of Configuring Oracle Secure Enterprise Search to Require SSL to the file /tmp/SESIdentityCertificate.crt.
Import the exported OHS certificate created in step 1h to Oracle SES. To do this, run the following command from ORACLE_HOME:
keytool –file [LocationOfOHSIdentityCertificate] -alias [MyOHSCerAlas] -import -trustcacerts -keystore [LocationofSESTrustStore] -storepass [MyPasswordForTheTrustStore] -storetype jks
For example, if the location of the exported OHS identity certificate is tmp/OHSIdentityCertificate.crt, the Oracle SES trust store is at ORACLE_BASE/wlserver/server/lib/SESTrust.jks, the store password is welcome1, and the alias is ohsCert, then run the following:
> keytool -file tmp/OHSIdentityCertificate.crt -alias ohsCert -import -trustcacerts -keystore $ORACLE_BASE/wlserver/server/lib/SESTrust.jks -storepass welcome1 -storetype jks
Import the Oracle SES certificate into OHS wallet. The Oracle SES certificate is the file SESIdentityCertificate.crt exported in step 4a. To import this certificate, from the Oracle Wallet Manager utility, click Operations and select Import Trusted Certificate. Navigate to the location of the exported Oracle SES certificate (/tmp/SESIdentityCertificate.crt), and import it as a trusted certificate.
Restart Oracle HTTP Server. Before restarting the server, ensure that the Auto Login option is enabled in Oracle Wallet Manager. The restart fails if the option is not enabled.
To restart the server, run the following command from ORACLEOHS_HOME/instances/instance1/bin/:
opmnctl restartproc process-type=OHS
Restart SSL for the Oracle WebLogic Server. To do this, use the control page of the server.
To access the control page, click Environment, then Server, and then Control.
See Also:
Oracle Database Advanced Security Administrator's Guide for more information about Oracle Wallet ManagerOracle Database Advanced Security Administrator's Guide for more information about the orapki utility
Oracle HTTP Server Administering a Standalone Deployment Based on Apache 2.0 for more information about enabling SSL for OHS
To log in to the Oracle SES application on the Windows platform, you can choose to implement the user authentication mechanism at the Oracle SES application layer, which involves logging in through the Oracle SES login page, or at the Windows operating system layer.
If you enable authentication at the Windows OS layer, then when you log in to a machine using your Windows user credentials, you can automatically access the Oracle SES application as a logged user. You are not required to provide additional authentication credentials to access the Oracle SES application. This is implemented using the Single Sign-On authentication mechanism. To implement this mechanism, the Oracle SES Identity plugin must be integrated with the Active Directory that manages Windows user authentication. The authentication is implemented using the Kerberos encryption mechanism.
To activate Windows authentication, you must perform the following steps:
Configure the Active Directory. See "Configuring the Active Directory".
Activate the Active Directory Plug-in in Oracle SES. See "Activating the Active Directory Identity Plug-in"
Activate Windows Native Authentication in Oracle SES. See "Activating Windows Native Authentication on Oracle SES".
The Active Directory is available on the Windows Server. As a first step, configure this active directory.
To configure the Active Directory:
In the Active Directory server, create a user account called seswna for the Oracle SES instance. To do this, select New, and then User. Specify a password for the user. Do not select the User must change password at next logon option.
Configure the new user account to comply with Kerberos protocol. Ensure that the user account's encryption type is set to DES and the user account requires Kerberos pre-authentication. To implement this:
Right-click the user name and select Properties.
Click the Account tab and select Use DES encryption types for this account.
Reset the user password. To do this, right-click the user name, select Reset Password, and re-enter the same password that you set earlier. (This step is recommended because setting the encryption type may corrupt the password that you set initially).
Create the Service Principal Names (SPNs) for the user account. To do this, use the setspn utility. Enter the following command:
setspn -a HTTP/<ses-host-name> seswna
where <ses-host-name> must be a fully qualified network address like sesmachine.us.oracle.com.
Create a user mapping using the ktpass utility. Enter the following command:
ktpass -princ HTTP/<ses- host-name>@<ad-domain-name> -pass <mapuser_password> -mapuser seswna –out c:\temp\seswna.HTTP.keytab –crypto DES-CBC-CRC
Copy the keytab file seswna.HTTP.keytab to the Oracle SES instance at ORACLE_HOME/search/base_domain/servers/AdminServer/folder.
After configuring the seswna user in the active directory, you must set up an identity plug-in for Active Directory. This identity plug-in must be configured to the Active Directory where seswna is created. See "Activating the Active Directory Identity Plug-in" for more information about activating the plug-in.
As the final step, activate WNA on Oracle SES.
To activate Windows native authentication on Oracle SES:
On the Home page, click Global Settings to open the Global Settings page.
Under Out-of-Box Query Application, click Configure Single Sign-On to open the Configure Single Sign-On page.
Select WNA from the list of available Single Sign-On types, and click Activate to enable Windows native authentication.
Restart the middle tier to activate WNA.
To deactivate Windows Native Authentication, on the Configure Single Sign-on page, click Deactivate, and then restart the middle tier.
Whenever a user tries to access the Oracle SES application, the following events are executed:
The Oracle SES application checks if Windows native authentication is enabled or not.
If it is enabled, then the user is directed to the Search page and is able to use the application as a logged in user.
If it is disabled, then the user is redirected to the Oracle SES Login page.
If a user performs an explicit log out from the application, then the user must use the Oracle SES Login page to log in to the application again.
Note that only the Windows user is automatically logged in to the Oracle SES application. If other users wish to use the application as logged users, then they must log in through the Oracle SES Login page. Also, if a user logs in from a Windows machine that is in a domain different from the domain of the Oracle SES Active Identity plugin, then the user is not automatically logged in to the Oracle SES application, and must log in through the Oracle SES Login page.
Windows Native Authentication is currently supported in the following Web browsers: Microsoft Internet Explorer and Mozilla Firefox.
To use WNA on Microsoft Internet Explorer, you must perform the following steps:
To configure the local intranet domain, perform the following steps:
In Internet Explorer, select Tools, and then Internet Options.
From the Internet Options dialog box, select the Security tab.
Select Local intranet and then click Sites.
In the Local intranet dialog box, ensure that the options Include all sites that bypass the proxy server and Include all local (intranet) sites not listed in other zones are selected.
Click Advanced.
Add all relative domain names that are used for Oracle WebLogic Server instances participating in the Single Sign-On configuration (for example, myhost.example.com) and click Close.
On the Local intranet dialog box, Click OK.
To configure Intranet authentication, perform the following steps:
In Internet Explorer, select Tools, and then Internet Options.
From the Internet Options dialog box, select the Security tab.
Select Local intranet, and then click Custom level. This opens the Security Settings-Local Intranet Zone dialog box.
Under User Authentication, select Automatic Logon only in Intranet Zone. Note that this option prevents users from having to re-enter log in credentials.
Click OK.
If you have a proxy server enabled, then you must verify the proxy settings. To do this:
In Internet Explorer, select Tools, and then Internet Options.
From the Internet Options dialog box, select the Connections tab.
Click LAN Settings to open the Local Area Network (LAN) Settings dialog box.
Verify that the proxy server address and the port number are correct.
Click Advanced to open the Proxy Settings dialog box.
Ensure that the required domain names are entered in the Exceptions field.
Additionally, for Internet Explorer 6.0, you must perform the following:
In Internet Explorer, select Tools, and then Internet Options.
From the Internet Options dialog box, select the Advanced tab.
Under Security, ensure that the option Enable Integrated Windows Authentication is selected.
If this option was not previously set, then restart the computer after setting the option.
In Mozilla Firefox, perform the following steps to use WNA:
In the Location bar, enter the string about:config. This opens the about:config page in Firefox.
In the Filter field, enter the string network.negotiate.
Set the preferences given in Table 11-7. To set the value for a preference, double-click the preference, and enter the value.
Table 11-7 WNA Configuration Preference for Firefox
| Preference Name | Status | Type | Value |
|---|---|---|---|
|
network.negotiate-auth.allow-proxies |
default |
boolean |
true |
|
network.negotiate-auth.delegation-uris |
User set |
string |
http://,https:// |
|
network.negotiate-auth.gsslib |
Default |
string |
<blank>1 |
|
network.negotiate-auth.trusted-uris |
User set |
string |
http://,https:// |
|
network.negotiate-auth.using-native-gsslib |
Default |
boolean |
true |
Note:
In previous releases, the base path of Oracle SES was referred to asORACLE_HOME. In Oracle SES release 11g, the base path is referred to as ORACLE_BASE. This represents the Software Location that you specify at the time of installing Oracle SES.
ORACLE_HOME now refers to the path ORACLE_BASE/seshome.
For more information about ORACLE_BASE, see "Conventions".
|
 Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|