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 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 administrator is searchsys, who is also the WebLogic Server identity store user. The password for the searchsys user is specified during the installation. A password must consist of at least 8 characters, and it must contain at least one numeric and one alphabetic character. Note that the password length cannot exceed 30 characters. The password can only be changed using the WebLogic Server Administration Console.
To change the Oracle SES administrator password:
Log in to the WebLogic Server Administration Console.
Under the Domain Structure in the left panel, click Security Realm.
In the Summary of Security Realms section, click myrealm.
Click the Users and Groups tab.
Click searchsys from the list of users.
Click the Passwords tab.
Enter and confirm the new password.
Save the changes.
Note:
Thesearchsys user in the WebLogic Server identity store is different from the searchsys schema user of the Oracle SES database. Refer to the Oracle Database documentation for changing password for a Database schema user.The following sections describe the steps for setting the Oracle SES users passwords in the WebLogic Server middle tier, if you change the passwords for the Oracle SES Database schema users searchsys, search_ess, and search_mds.
Setting the SEARCHSYS Schema User Password in WebLogic Server Middle Tier
Setting the SEARCH_ESS Schema User Password in WebLogic Server Middle Tier
Setting the SEARCH_MDS Schema User Password in WebLogic Server Middle Tier
If you change the password for the searchsys schema user of the Oracle SES database, then the following passwords related to the WebLogic Server configuration also need to be changed:
Data source connection pool password
Credential Storage Framework (CSF) password
Note:
If Oracle SES software is installed on an existing Database, then shut down the Oracle SES server and Oracle ESS server before executing the steps for changing the password related to the WebLogic Server configuration. Refer to "Starting and Stopping Oracle SES Instance" for more information about starting and stopping WebLogic Server, Oracle ESS Server, and Oracle SES Server.To change the data source connection pool password for SEARCHSYS user:
Log in to the WebLogic Server Administration Console.
Under the Change Center in the left panel, click Lock & Edit.
Change the password for SearchAdminDS data source:
Under the Domain Structure in the left panel, select search_domain > Services > Data Sources. The Configuration tab for the settings for SearchAdminDS is displayed in the main panel.
In the Name column of the Data Sources table, click SearchAdminDS. The General tab of the settings for SearchAdminDS is displayed.
Select the Connection Pool tab.
Enter and confirm the new password.
Save the changes.
Change the password for SearchQueryDS data source:
Under the Domain Structure in the left panel, select search_domain > Services > Data Sources. The Configuration tab for the settings for SearchQueryDS is displayed in the main panel.
In the Name column of the Data Sources table, click SearchQueryDS. The General tab of the Settings for SearchQueryDS is displayed.
Select the Connection Pool tab.
Enter and confirm the new password.
Save the changes.
Click Activate Changes under the Change Center in the left panel.
Restart the WebLogic Server.
To change the Credential Storage Framework (CSF) password for SEARCHSYS user:
Connect to the system where WebLogic Server middle tier is installed.
Go to MW_HOME/oracle_common/common/bin.
Start the WebLogic Server Administration Scripting Tool by executing the command wlst.sh on Linux and UNIX platform, and command wlst.cmd on Windows platform.
Run the connect() command at the wls/offline> prompt. You will be prompted to enter the following values:
WebLogic Server user name
WebLogic Server password
WebLogic Server URL
Run the following command at the wls:domain_name/serverConfig> prompt:
updateCred(map="oracle.apps.security",key="FUSION_APPS_ECSF_SES_ADMIN-KEY", user="searchsys", password="password")
where,
password is the SEARCHSYS user password, and the Oracle SES credentials for connecting to the Oracle Database are obtained from a CSF map named oracle.apps.security with a key named FUSION_APPS_ECSF_SES_ADMIN-KEY.
If you change the password for the search_ess schema user of Oracle SES database, then the data source connection pool password related to WebLogic Server configuration also needs to be changed.
Note:
If Oracle SES software is installed on an existing Database, then shut down the Oracle SES server and Oracle ESS server before executing the steps for changing the password related to the WebLogic Server configuration. Refer to "Starting and Stopping Oracle SES Instance" for more information about starting and stopping WebLogic Server, Oracle ESS Server, and Oracle SES Server.To change the data source connection pool password for SEARCH_ESS user:
Log in to the WebLogic Server Administration Console.
Under the Change Center in the left panel, click Lock & Edit.
Change the passwords for EssDS, EssInternalDS, and EssXADS data sources:
Under the Domain Structure in the left panel, select search_domain > Services > Data Sources. The Configuration tabs for the settings for EssDS, EssInternalDS, and EssXADS is displayed in the main panel.
In the Name column of the Data Sources table, click EssDS, EssInternalDS, and EssXADS, one by one, to change their passwords. The General tab of the Settings for EssDS/EssInternalDS/EssXADS is displayed.
Select the Connection Pool tab.
Enter and confirm the new password. All the three data sources - EssDS, EssInternalDS, and EssXADS - should have the same password, which is the search_ess schema password.
Save the changes.
Restart the WebLogic Server.
If you change the password for the search_mds schema user of the Oracle SES database, then the data source connection pool password related to WebLogic Server configuration also needs to be changed.
Note:
If Oracle SES software is installed on an existing Database, then shut down the Oracle SES server and Oracle ESS server before executing the steps for changing the password related to the WebLogic Server configuration. Refer to "Starting and Stopping Oracle SES Instance" for more information about starting and stopping WebLogic Server, Oracle ESS Server, and Oracle SES Server.To change the data source connection pool password for SEARCH_MDS user:
Log in to the WebLogic Server Administration Console.
Under the Change Center in the left panel, click Lock & Edit.
Change the passwords for mds-ESS_MDS_DS and mds-owsm data sources:
Under the Domain Structure in the left panel, select search_domain > Services > Data Sources. The Configuration tabs for the settings for mds-ESS_MDS_DS and mds-owsm is displayed in the main panel.
In the Name column of the Data Sources table, click mds-ESS_MDS_DS and mds-owsm, one by one, to change their passwords. The General tab of the settings for mds-ESS_MDS_DS/mds-owsm is displayed.
Select the Connection Pool tab.
Enter and confirm the new password. All the two data sources - mds-ESS_MDS_DS and mds-owsm - should have the same password, which is the search_mds schema password.
Save the changes.
Restart the WebLogic Server.
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.
When 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, ensure 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 |
|
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 |
|
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 |
|
Oracle WebCenter |
11g |
Active Directory, Oracle Internet Directory, Sun Java System Directory Server for using Oracle Unified Directory (OUD) |
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.
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 |
|
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 |
|
Oracle Fusion |
oracle.search.plugin.security.identity.fusion.FusionIdentityPluginMgr |
../oracleapplications/FusionCrawler.jar |
|
PeopleSoft |
oracle.search.plugin.security.identity.psft.PsftIdentityPluginMgr |
../oracleapplications/PeoplesoftCrawler.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 |
|
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), 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 searchsys by default. This user is natively defined in Oracle SES. Only this user can use the Oracle SES Administration GUI.
If the Single-Sign On (SSO) is enabled, then the SSO user can also 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 searchsys administrative user, the login screen is available in the Oracle SES Administration GUI. If the Single Sign-on (SSO) is enabled, then the administrative user can access the Oracle SES Administration GUI using the SSO login screen.
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 using 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:
At any point in time, only one method of authentication can be used for a search user or for an administrative user.
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:
Oracle SES Administration TutorialThe 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-delimited 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-delimited 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) If the Oracle SES software is deployed across multiple middle tiers, then this remote cache configuration file must be accessible to all the middle tiers. |
|
Password |
Password for the searchsys 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>
The name of a UAC source in a remote instance of Oracle SES from which the federated UAC retrieves user and attribute information. (Required)
Not supported in this release.
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 wls_domain_home/ses_domain_name/servers/AdminServer/logs/.
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.
See Also:
"Query-time Authorization API" for more information about the Query-time Authorization API of Oracle SES Java SDKQuery-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 query 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.
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.
Self 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 query 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 the Oracle WebLogic Server, which is installed in wls_home directory.
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 (OHS) 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 wls_home/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 register it, 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 Oracle HTTP Server 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. Take these 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:
> $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. 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:
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>
OssoIdleTimeout off
OssoIpCheck 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 SSO for Oracle SES:
Add OSSO provider for WebLogic domain as described in "Adding OSSO Provider for WebLogic Domain".
Add OSSO Identity Asserter as described in "Adding OSSO Identity Asserter".
Add OID Authenticator as described in "Adding OID Authenticator".
Enable OSSO for Oracle SES as described in "Enabling OSSO for Oracle SES".
To add an OSSO provider for WebLogic domain, perform the following steps:
Copy the file ORACLEOHS_HOME/modules/oracle.ossoiap_11.1.1/ossoiap.jar to the following WebLogic Server directory:
wls_home/server/lib/mbeantypes
Note:
Theossoiap.jar file 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 middle tier.
To add an OSSO Identity Asserter to the domain, perform the following steps:
Log in to the WebLogic Server 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.
Save the changes.
Restart the WebLogic Server.
To add an Oracle Internet Directory (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 OracleAS Single Sign-On Identity Asserter and Oracle Internet Directory 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 the 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.
Set the order of the authentication providers and the values of their control flags as follows:
DefaultAuthenticator: SUFFICIENT
OIDAuthenticator: SUFFICIENT
OSSOIdentityAsserter: SUFFICIENT
DefaultIdentityAssert: This does not have a control flag.
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.
Restart Oracle WebLogic Server.
To enable OSSO for Oracle SES, perform the following steps:
In the Administration GUI, click Configure Single Sign-On link in the Global Settings tab.
Select the OSSO option, and click Activate.
Enter the following parameter values for OSSO:
Hint cookie enabled: Specify true to enable hint cookie. Specify false to disable it.
Hint cookie name: Specify a name for the hint cookie when hint cookie is enabled.
Query invalid session return URL: Specify the URL to display when the query application session expires.
Query logout return URL: Specify the URL to display after logging out of the query application.
Click Finish.
You can implement an SSO authentication mechanism for Oracle SES by using Oracle Access Manager (OAM).
Note:
This section describes SSO configuration steps for OAM version 10g. For OAM version 11g, refer to Oracle Secure Enterprise Search Release Notes.Ensure that the following components are installed:
Oracle Access Manager 10.1.4.3.0 or later. See Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
Oracle HTTP Server (OHS) 11g.
Oracle Internet Directory (OID) 10.1.4.3.0 or later. See Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. Also see "Adding OAM Identity Asserter" for information on configuring OID.
Oracle HTTP Server WebGate.
You must install OAM and add an entry for WebGate in OAM before installing WebGate. Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management provides detailed information about installing WebGate. Follow the steps as provided in this guide. However, for some steps, such as creating a WebGate instance and installing 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.
To configure OAM SSO for Oracle SES:
Add OAM Identity Asserter as described in "Adding OAM Identity Asserter".
Add OID Authenticator as described in "Adding OID Authenticator".
Configure Oracle HTTP server as described in "Configuring Oracle HTTP Server".
Install and Configure WebGate as described in "Installing and Configuring WebGate".
Integrate OAM with Oracle SES as described in "Integrating OAM with Oracle SES".
To add an OAM Identity Asserter to the domain, perform the following steps:
Log in to the WebLogic Server 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: OAM Identity Asserter
Type: OAMIdentityAsserter
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.
Save the changes.
Restart the WebLogic Server.
To add an Oracle Internet Directory (OID) Authenticator to the domain, perform the following steps:
Log in to the WebLogic Server 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
Save the changes.
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:
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 the changes.
Restart the WebLogic Server.
After adding OAM 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 the 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.
Set the order of the authentication providers and the values of their control flags as follows:
DefaultAuthenticator: SUFFICIENT
OIDAuthenticator: SUFFICIENT
OAMIdentityAsserter: SUFFICIENT
DefaultIdentityAssert: This does not have a control flag.
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.
Restart Oracle WebLogic 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 (OAM). The WebGate intercepts HTTP requests from users for Web resources and forwards them to the Access Server for authentication and authorization. See Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management 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 user ID. 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:
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: OAM_REMOTE_USER
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. The steps are identical to the previous step. However, for step 3g, the form login scheme must be Anonymous Authentication under Authentication Rule.
Turn on the OAM Single Sign-On using the Administration GUI by navigating to the Global Settings > Configure Single Sign-On page, selecting the OAM option, and clicking Activate.
Enter the following parameter values for OAM SSO:
Admin logout return URL: Specify the URL to display after logging out of the administration application.
Query invalid session return URL: Specify the URL to display when the query application session expires.
Query logout return URL: Specify the URL to display after logging out of the query application. Specify this URL format depending upon the WebGate version.
Note:
The format of the logout return URLs for administration and query applications must be as follows:For WebGate 10g: /oamsso/logout.html?end_url=return_url
where,
return_url is the page that is displayed after logging out of the application. For example, to return to the default query application page, set return_url to /search/query.
For WebGate 11g: oam_logout_url?end_url=return_url
where,
oam_logout_url is the OAM Logout URL. For example, http://oam_server_host:oam_server_port/oam/server/logout
return_url is the page that is displayed after logging out of the application. For example, to return to the default query application page, set return_url to http://ses_host:ses_port/search/query.
Click Finish.
Note:
If you protect the Oracle SES instance using OAM SSO, then it is recommended to protect both the Oracle SES applications - Administration application and Query application.
If you chose to protect only one of the Oracle SES applications using OAM SSO, that is, either the Administration application and or the Query application, then you must configure the logout URL parameter for the unprotected application using either the Administration GUI or the Administration API.
For example, if the Administration application is unprotected, then the Administration URL must be set to be excluded from OAM resource, and the Administration Logout URL must be set to a non-SSO logout URL, such as /search/admin/control/logout.jsp.
If you protect the Administration application using OAM SSO, then you must either add the searchsys user to the OID used for SSO, or grant the SearchAdminSuperUserRole role to an existing user in OID. Also set the appropriate Administration Logout URL for SSO.
See Also:
"Configuring Centralized Logout for 11g [or 10g] WebGate with OAM 11g Servers" in the Oracle Access Manager Access Administration GuideFor 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://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
For connectors that interact with external SSL-enabled repositories at crawl time and query time, you must import the SSL certificate into the keystore location of the Oracle SES middle tier, that is, into the WebLogic Server directory wls_home/server/lib.
Depending on the requirement, 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 java_home/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://docs.oracle.com/javase/6/docs/technotes/tools/solaris/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 used along with the Oracle HTTP Server, Oracle recommends that Oracle SES be configured to use SSL with client-side authentication for communication with the Oracle HTTP Server. Furthermore, use a keystore other than the default one. Oracle recommends 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 create the keystore:
Log in to the WebLogic Server Administration Console.
Expand the Environment button and click Servers. This takes you to the configuration page for the servers.
Click 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. To create a new keystore SESIdentity.jks, add the path and name wls_home/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. To create a new keystore SESTrust.jks, add the path and name wls_home/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. Use Sun Microsystem's keytool utility to perform the following steps:
Generate the key for the identity keystore by executing the following keytool command from the java_home/bin directory:
>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 wls_home/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 executing the following keytool command from the java_home/bin directory:
> keytool -genkey -keyalg RSA -alias sescert -keysize 1024 -dname "CN=example0123.us.mycompany.com,OU=ses,O=oracle,C=us" -keypass welcome1 -keystore wls_home/server/lib/SESTrust.jks -storepass welcome1 -storetype jks
Certify the generated keys by running the following command:
> keytool -selfcert -alias sescert -keyalg RSA -validity 2000 -keypass welcome1 -keystore wls_home/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:
> keytool -selfcert -alias sescert -keyalg RSA -validity 2000 -keypass welcome1 -keystore wls_home/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://docs.oracle.com/cd/E12840_01/wls/docs103/secmanage/identity_trust.htmlConfigure Oracle SES to use the generated key:
Log in to the WebLogic Server Administration Console.
Select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. The configuration page for servers is displayed.
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 changes.
(Optional) Enable two-way-SSL for Oracle SES:
Log in to the WebLogic Server Administration Console.
Select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. The configuration page for servers is displayed.
Click the SSL tab.
Click Advanced link present at the bottom of the page.
Set the parameter Two Way Client Cert Behavior value to Client Certs Requested and Enforced.
Save the changes and restart the SSL channel.
(Optional) Enable WebLogic plugin when the WebLogic Server is used along with the Oracle HTTP Server that uses WebLogic proxy plugin:
Log in to the WebLogic Server Administration Console.
Select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. The configuration page for servers is displayed.
Click the General tab.
Click Advanced link present at the bottom of the page.
Select Weblogic plugin enabled.
Save the changes and restart the Oracle SES server.
Enable SSL for Oracle SES:
Log in to the WebLogic Server Administration Console.
Select the server for which you want to configure SSL by expanding the Environment button and clicking on Servers. The configuration page for servers is displayed.
Click the General tab.
Select SSL Listen Port Enabled and provide a port number. The default port is 7002.
Save the changes.
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 Oracle HTTP Server (OHS) to use 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:
From ORACLEOHS_HOME/bin, run owm, where, ORACLEOHS_HOME is the root directory of the Oracle HTTP Server (OHS).
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 ORACLEOHS_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 reopen it, close and open the wallet by selecting the correct directory. You should now see Certificate:[Ready] under the wallet.
Save the changes.
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 Server. To exchange them, 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 Use SSL to a suitable location by running the following command from the Oracle SES directory java_home/bin:
> keytool -export -alias sescert -keystore wls_home/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 Use SSL to the file /tmp/SESIdentityCertificate.crt.
Import the exported OHS certificate created in step 1h to Oracle SES. To import it, run the following command from the Oracle SES directory java_home/bin:
> 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 wls_home/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 wls_home/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 WebLogic Server by using 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 computer 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 plug-in must be integrated with the Active Directory that manages Windows user authentication. The authentication is implemented using the Kerberos encryption mechanism.
Note:
In the earlier Oracle SES release (11.1.2.2), when Oracle SES is integrated with Windows Native Authentication (WNA), the user is logged into the query application automatically regardless of the query application secure mode. This behavior is changed in Oracle SES 11.2.2.2. In Oracle SES 11.2.2.2:If the secure mode of query application is "require login for both public and secure content", then a user is automatically logged into the query application. After logging out, the user is redirected to the login page.
If the secure mode of query application is "require login for secure content", then a user must again provide authentication credentials to login to the query application. After logging out, the user is redirected to the default search page.
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".
Enable WNA SSO for Oracle SES as described in "Enabling WNA SSO for 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:
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. Right-click the user name, select Reset Password, and reenter 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 by using 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.xyz.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 an Oracle SES middle tier directory. If your Oracle SES environment has multiple middle tier host systems, then you need to repeat the above two steps (3 and 4) for each middle tier host system, and copy the seswna.HTTP.keytab file to each middle tier host system.
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 Active Directory plug-in.
To create and configure JAAS login file, perform the following steps:
Create a text file with the name krb5Login.conf.
Add the following text to the krb5Login.conf file:
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal="HTTP/ses_hostname@REALM.NAME" useKeyTab="true"
keyTab="keytab_file_name" storeKey="true" debug="true";
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule Required
principal="HTTP/ses_hostname@REALM.NAME" useKeyTab="true"
keyTab="keytab_file_name" storeKey="true" debug="true";
};
where, keytab_file_name must be replaced with the file path of seswna.HTTP.keytab file.
Copy the krb5Login.conf file to an Oracle SES middle tier directory. If your Oracle SES environment has multiple middle tier host systems, then copy the krb5Login.conf file to each middle tier host system.
To add Negotiate Identity Assertion provider, perform the following steps:
Log in to the WebLogic Server Administration Console.
Acquire lock to make changes.
Expand the Security > Realms nodes.
Select the name of the realm.
Expand the Providers > Authentication Providers nodes.
On the Authenticators tab, click Configure a new Negotiate Pass Identity Asserter.
Specify the Negotiate Identity Assertion provider name, and select Negotiate Identity Asserter type as the provider type.
Save the changes.
To add Active Directory Authenticator, perform the following steps:
Log in to the WebLogic Server Administration Console.
Acquire lock to make changes.
Expand the Security > Realms nodes.
Select the name of the realm.
Expand the Providers > Authentication Providers nodes.
On the Authenticators tab, click Configure a new ActiveDirectoryAuthenticator.
Specify the Active Directory Authenticator name, and in the Common Authentication Provider Settings page, change the value for Control Flag from REQUIRED to SUFFICIENT.
Save the changes.
Click the Provider Specific tab and edit the Active Directory LDAP settings:
Connection
Host: The Windows system name on which the Active Directory is installed.
Port: The port to which the Active Directory is listening to.
Principal: The LDAP DN for the user to connect to the Active Directory, for example, cn=jsmith,cn=users,dc=us,dc=xyzcorp,dc=com.
Credential/Confirm Credential: Password for the Principal.
Groups
Group Base DN: The LDAP query to find groups in the Active Directory.
Users
User Base DN: The LDAP query to find users in the Active Directory.
User Object class: User object class, for example, user.
Use Retrieved User Name as Principal: Select this check box.
User Attributes: Following are the user attributes containing the user related information in the Active Directory. You can either use the default settings or specify new settings for these attributes.
| Attribute Name | Attribute Description | Default Setting | Specify New Setting |
|---|---|---|---|
| UserNameAttribute | User name in Active Directory. | cn | <UserAttribute> |
| AllUsersFilter | The LDAP search filter for all the users. | (&(cn=*)(objectclass=user)) | (&(<UserAttribute> =*)(objectclass=person)) |
| UserFromNameFilter | The LDAP search filter for a particular user. | (&(cn=%u)(objectclass=user)) | (&(<UserAttribute>=%u)(objectclass=person)) |
General
GUID attribute: The attribute used to define object GUIDs in Active Directory, for example, objectguid.
Save the changes.
Set the control flag of DefaultAuthenticator to SUFFICIENT.
Reorder the Authentication providers as follows:
DefaultAuthenticator
DefaultIdentityAsserter
ActiveDirectoryAuthenticator
NegotiateIdentityAsserter
Restart the WebLogic Server.
To configure startup arguments for Kerberos authentication, perform the appropriate steps depending upon whether the WebLogic Server is running without nodemanager or with nodemanager.
To configure startup arguments for Kerberos authentication with WebLogic Server running without a nodemanager:
Open the setDomainEnv.sh file in a text editor.
Add the following lines before the line beginning with JAVA_OPTIONS="${JAVA_OPTIONS}":
WLS_WNA_JVM_OPTIONS="-Djava.security.auth.login.config=krb5Login.conf_file_location -Djava.security.krb5.realm=Active_Directory_Realm -Djava.security.krb5.kdc=KDC_hostname -Dweblogic.security.enableNegotiate=true"
where,
conf_file_location is the directory path of the JAAS login file krb5Login.conf created earlier as described in section "Creating and Configuring JAAS Login File".
Active_Directory_Realm is the Active Directory realm name.
KDC_hostname is the Active Directory host name.
Update the line JAVA_OPTIONS="${JAVA_OPTIONS}" to:
JAVA_OPTIONS="${JAVA_OPTIONS} ${WLS_WNA_JVM_OPTIONS}"
Export the WLS_WNA_JVM_OPTIONS variable:
export WLS_WNA_JVM_OPTIONS
Restart the WebLogic Server.
If the WebLogic Server is running with nodemanager, then to configure startup arguments for Kerberos authentication, you can either execute the above described steps, or you can add the WLS_WNA_JVM_OPTIONS property value to the Server Start arguments for the Oracle SES server (search_server1).
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 the 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 reenter 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> |
|
network.negotiate-auth.trusted-uris |
User set |
string |
http://,https:// |
|
network.negotiate-auth.using-native-gsslib |
Default |
boolean |
true |
To enable WNA SSO for Oracle SES, perform the following steps:
In the Administration GUI, click Configure Single Sign-On link in the Global Settings tab.
Select the WNA option, and click Activate.
A master encryption key is used to encrypt secure fields in Oracle SES. You can change this key if its security is compromised or for any other reason.
To change the master encryption key:
Stop all crawler schedules.
Close all middle-tier applications, except for the Monitor application.
Open an interactive session on the Oracle SES middle-tier computer.
Issue a searchctl rollover_key command. See the following description.
Restart the crawler and the middle-tier applications.
This command has the following syntax:
searchctl rollover_key options
Options have the format keyword=value:
Local JDBC connection string for the Oracle SES database. For example, localhost:5555:ses1. Required.
Oracle SES administrator's password. If you omit this password from the command, then you are prompted for it.
URL to the WebLogic Server Administration Console. For example, t3://wls_example:8000. Required.
User name of the WebLogic administrative user. (Required)
Password of the WebLogic administrative user. If you omit this password from the command, then you are prompted for it.
New master key. If you omit this option, a random master key is set.
The following command changes the master key to "testing123";
searchctl rollover_key ses_db_conn_str=localhost:5555:ses1 ses_admin_passwd=password wls_admin_user=weblogic wls_admin_passwd=password wls_admin_server=t3://asHost:8000 master_key=testing123