This section describes the Oracle SES security model. It contains the following topics:
Oracle SES provides access to a variety of content repositories through a single gateway. Each external repository has its own security model that determines whether a particular user can access a particular document. You must carefully consider all aspects of security in Oracle SES to respect the security of documents coming from multiple data repositories.
Oracle SES uses the following security services in its security model:
Identity plug-ins can obtain user and group information directly from any identity management system. An identity plug-in is Java code between Oracle SES and an identity management system, allowing Oracle SES to read user and group information.
Secure Socket Layers (SSL) is the industry standard protocol for managing the security of message transmission on the Internet. This is used for securing RMI connections, HTTPS crawling, and secure JDBC.
Connecting to the Oracle SES server using SQL*Plus, except as documented in the guide, is not supported. Changing the Oracle SES server directly using SQL and modifying initialization parameter files is not supported. User management, including password changes, should only be done using the Oracle SES Administration GUI.
As an additional security measure, Oracle SES is configured to reject connection requests using SQL*Plus from remote hosts. The only protocols supported for connection to Oracle SES from remote hosts are HTTP, HTTPS, and AJP13.
The user name for Oracle SES is eqsys. You can change the password specified during installation on the Global Settings - Change Password page. A password must consist of at least 8 characters, and contain at least one numeric and one alphabetic character. Note that the password length cannot exceed 30 characters. After you click Apply, a confirmation message appears if the password changed successfully.
For added security, a temporary password feature is provided. You can enter login credentials for use by the crawler when creating table sources, e-mail, OracleAS Portal, or Web sources. For Web sources, authentication can be performed with HTTP authentication, HTML forms, and OracleAS Single Sign-On.
To use the temporary password feature:
Select the Delete Passwords After Crawl option in the Oracle SES Administration GUI when creating or editing a source.
This option is not available when self service for Web sources is enabled.
If a source has the Delete Passwords after Crawl option enabled, then you are prompted for all required passwords whenever the schedule for that source starts. You must start these schedules manually, which enables you to respond to the prompts. The supplied passwords are removed immediately after the schedule completes.
Oracle SES security is implemented at two levels: user authentication and user authorization.
This section contains the following topics:
User authentication identifies a user through an identity management system. You can register an identity plug-in to any identity management system; Oracle SES provides registered identity plug-ins for many identity management systems. The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Activation is performed on the Global Settings - Identity Management Setup page.
Security filter configuration for the identity plug-in is performed on the Global Settings - Query Configuration page. A login does not force a refresh of the user's security filter. For a query request, Oracle SES checks the timestamp of an existing cached security filter and refreshes it when the specified life span has expired. The default latency is 60 minutes.
User authorization determines whether a user can access information about a particular item in the result list. It can be implemented in two layers.
The first layer utilizes access control lists (ACLs). An ACL lists the users or groups of users that have access to the document. The ACL can be assigned by the administrator to an entire source through the Oracle SES Administration GUI (source-level ACLs), or it can be provided by the source itself for each document (document-level ACLs).
The second layer uses a Java class to dynamically filter documents at search time (query-time authorization).
Oracle SES can use the following types of ACL policies:
Source-level ACLs: An individual source can be protected by a single ACL, which governs access to every document in that source. These ACLs are defined on the Home - Sources - Authorization page.
Document-level ACLs: Oracle SES provides mapped security to repositories by retrieving the ACL for each document at the time of crawling and indexing. At crawl time, the ACL for each document is passed to the crawler along with the document content, and the ACL is stored in the index. Currently Oracle SES supports document-level ACLs for user-defined sources and OracleAS Portal sources. (The ACL policy is Documents Controlled by the Source.) With user-defined sources, ACLs are returned by the crawler plug-in implemented by the user. With OracleAS Portal sources, ACLs are returned by the OracleAS Portal server. At search time, Oracle SES does not need any connection with the repository to validate access privileges.
For both source-level ACLs and document-level ACLs, all users and roles defined in the ACLs must exist in the identity plug-in.
User names are not case sensitive.
Table 11-1 identifies when documents are visible with the document ACL types supported in Oracle SES:
Table 11-1 Document ACL Types in Oracle SES Security Model
| Document ACL Type | Public User | Authenticated User | Authenticated User with Allow Permission to Document | Authenticated User with Deny Permission to Document |
|---|---|---|---|---|
|
No ACL |
document visible |
document visible |
N/A |
N/A |
|
Deny Permission Only |
-- |
-- |
N/A |
-- |
|
Allow Permission Only |
-- |
-- |
document visible |
N/A |
|
Deny with Allow Permissions |
-- |
-- |
document visible |
-- |
Table 11-2 compares the document-level user authorization methods in Oracle SES.
Table 11-2 User Authorization Methods in Oracle Secure Enterprise Search
| Method | How Authorization is Determined | Advantages | Disadvantages |
|---|---|---|---|
|
ACLs |
The ACL is supplied by a crawler plug-in or an OracleAS Portal server. |
Faster secure search performance. No additional programming is required for ACL-based OracleAS Portal security. (If implementing a crawler plug-in, then some additional work is necessary to supply ACLs.) |
ACLs are static: they are updated only when crawling the source repository or when the administrator changes Oracle SES ACLs in the Oracle SES Administration GUI |
|
Query-time Authorization |
|
Dynamic authorization. |
There is performance overhead in cases when the search is not selective, returning large number of rows before query-time authorization. Extra work is required to implement a |
For sources that do not fit the user/group model, an authorization plug-in provides a more flexible security model. With an authorization plug-in, a crawler plug-in can add security attributes similar to document attributes. The authorization plug-in is invoked at login time to build security filters onto the query string. The security filters are applied against the values of the security attributes for each document. Only documents whose security attribute values match the security filter are returned to the user.
See Also:
"Administrator-Based Authorization" for more information about ACLs
"Query-time Authorization" for more information on Java filter classes
On the Home - Sources - Authorization page, you can set and change the ACL policy.
The following ACL policy options are available:
No ACL: With this setting, all documents are considered searchable and visible
Oracle Secure Enterprise Search ACL: With this setting (also known as source-level ACLs), you can protect the entire source with one ACL. The same ACL protects every document in that source.
ACLs Controlled by the Source: This setting (also known as document-level ACLs) is available only for OracleAS Portal sources and user-defined sources. This preserves authorizations specified in OracleAS Portal. For user-defined sources, crawler plug-ins (or connectors) can supply ACL information with documents for indexing, which provides finer control document protection. (That is, each document in the source can have different access privileges.)
The following restrictions apply to changing the ACL policy:
If the schedule associated with the source is not currently being crawled, and if the source has never been crawled, then all ACL policy changes are allowed.
If the schedule associated with that source is currently being crawled (that is, the schedule status is Launching, Executing, or Stopping), then all ACL options are grayed out, and you cannot change the ACL policy.
If the schedule associated with the source is not currently being crawled, but the source has been crawled earlier, then the only change allowed is between No ACL and Oracle Secure Enterprise Search ACL (in either direction). This is visible in the Oracle SES Administration GUI as follows:
If the ACL option selected before the crawl started was No ACL or Oracle Secure Enterprise Search ACL, then the ACLs Controlled by the Source option is grayed out.
If a secure ACL policy was selected but the identity plug-in is deactivated, then you can change the ACL policy to No ACL regardless of the crawl status.
OracleAS Portal sources are subject to the same restrictions as other sources. That is, no changes are allowed while being crawled, and only changes between No ACL and Oracle Secure Enterprise Search ACL are allowed after crawling completes. However, the ACL policy for an OracleAS Portal source can also change if it is inheriting the ACL policy from its OracleAS Portal server parent; for example, when the OracleAS Portal server ACL policy is modified or when the OracleAS Portal source is changed from specifying the ACL policy locally to inheriting it from the server. Therefore, changes on an OracleAS Portal server are restricted so that no disallowed changes can occur on any children that inherit the ACL policy.
If any child inheriting the ACL policy is being crawled, then no changes are allowed on the OracleAS Portal server. If any child inheriting the ACL policy has been crawled, then the only changes allowed are between No ACL and Oracle Secure Enterprise Search ACL. (If the OracleAS Portal server policy is ACLs Controlled by the Source, then no changes are allowed). Similarly, the OracleAS Portal source cannot be set to inherit its ACL policy from the OracleAS Portal server if the associated change in ACL policy would be disallowed.
Note:
A source that is being crawled is different from a source whose associated schedule is being crawled. Oracle SES restricts all ACL policy changes for a source when the schedule associated with that source is being crawled. A source might not be crawled, but the schedule associated with it could be crawled if another source in the same schedule is being crawled.You can register an identity plug-in to any identity management system. Oracle SES provides registered identity plug-ins for many identity management systems. The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Activate an identity plug-in on the Global Settings - Identity Management Setup page.
When you activate a plug-in, the Global Settings - Activate Identity Plug-in page is displayed. When completing this page, 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 |
|
EMC Documentum eRoom |
7.3 |
Active Directory, Oracle Internet Directory |
|
FileNet Content Engine |
3.5 |
Active Directory |
|
FileNet Image Services |
4.0 (ISRA 3.2) |
Active Directory, Oracle Internet Directory, Native |
|
Hummingbird Document Management Server |
2004, 2005 |
Active Directory, Native |
|
IBM DB2 Content Manager |
8.3 |
Native |
|
Lotus Notes |
5.0.9, 6.5.4,7.0 |
Active Directory, Oracle Internet Directory, Native |
|
Microsoft Exchange |
Windows 2000, Windows 2003 |
Active Directory |
|
Microsoft SharePoint Portal Server |
2003, 2007 |
Active Directory |
|
NTFS |
Windows 2000, Windows 2003 |
Active Directory, Oracle Internet Directory |
|
Open Text Livelink |
9.2, 9.5, 9.5.5 |
Active Directory, Native |
|
Oracle Calendar |
10.1.2 or later |
Oracle Internet Directory |
|
Oracle Content Database |
Oracle Content Services 10.1.2 or later, Oracle Content Database 10.2 or 10.1.3 |
Native, Query-time authorization |
|
Oracle E-Business Suite |
11, 12 |
Native |
|
Oracle Mail |
10g |
Oracle Internet Directory |
|
Siebel 7.8 |
7.8 |
Native |
|
Siebel 8 |
8 |
Native |
|
Oracle Content Server |
7.1.1, 7.5.2, 10gR3 |
Native |
When connecting to Active Directory, Oracle SES tries to resolve the Active Directory domain name to an IP address of the Active Directory Domain Controller. This is generally not possible, especially when Oracle SES is installed on a non-Windows system or on a Windows system in a different domain. You must add the IP address of the Active Directory domain to the host file.
For example, to connect to an Active Directory domain called foobar.example.com, you must add something similar to the hosts file: 10.123.1.2 foobar.example.com. Search for the hosts file in C:\Windows\System32\Drivers\etc\HOSTS on Windows systems, and /etc/hosts on UNIX systems.
For the Active Directory identity plug-in enter values for the following parameters:
Directory URL: ldap://ActiveDirectoryserver:389
Directory account name: UserLogonName Confirm the user logon name on the Active Directory Users and Computers application. Under the User folder, right-click username. Select Property and go to the Account tab. For example, assume the user account adtest in domain domain1.example.com, which is associated with the target Active Directory. You may try domain1\adtest or adtest@domain1.example.com or cn=adtest,cn=users,dc=domain1,dc=example,dc=com if you are not sure the actual user logon name. The user account does not need to be an administrator account.
Directory account password: PasswordForDirectoryAccount
Directory subscriber: dc=domain1,dc=example,dc=com for the domain name domain1.example.com
Directory security protocol: none
If you deactivate an identity plug-in, then you must restart the middle tier with searchctl restart.
If a pre-installed identity plug-in is accidentally removed, you can re-register it with the following steps:
On the Global Settings - Identity Management Setup page, click Register New Identity Plug-in.
Enter the class name and jar file name of the removed identity plug-in, as identified in Table 11-4.
Click Finish.
Table 11-4 Identity Plug-in Class Names and Jar File Names
| Identity Plug-in | Plug-in Class Name | Jar File Name |
|---|---|---|
|
Documentum Content Services |
oracle.search.plugin.security.identity.dcs.DCSIdentityPluginManager |
../dcs/DCSIdentityPlugin.jar |
|
FileNet Image Services |
oracle.search.plugin.security.identity.fnis.FNISIdentityPluginManager |
../fnetis/FNISIdentityPlugin.jar |
|
Hummingbird DMS |
oracle.search.plugin.security.identity.hbdm.HBDMIdentityPluginManager |
../hbdm/HBDMIdentityPlugin.jar |
|
Open Text Livelink Content Services |
oracle.search.plugin.security.identity.llcs.LLCSIdentityPluginManager |
../llcs/LLCSIdentityPlugin.jar |
|
Database |
oracle.search.plugin.security.identity.db.DBIdentityPluginManager |
../oracleapplications/DBCrawler.jar |
|
Oracle E-Business Suite |
oracle.search.plugin.security.identity.ebs.EBSIdentityPluginMgr |
.../oracleapplications/EBSCrawler.jar |
|
Siebel 7.8 |
oracle.search.plugin.security.identity.siebel.Siebel78IdentityPluginMgr |
../oracleapplications/Siebel78Crawler.jar |
|
Siebel 8 |
oracle.search.plugin.security.identity.siebel.SiebelIdentityPluginMgr |
../oracleapplications/Siebel8Crawler.jar |
|
Oracle Content Server |
oracle.search.plugin.security.identity.stellent.StellentIdentityPluginMgr |
../oracleapplications/StellentCrawler.jar |
|
Oracle Internet Directory |
oracle.search.plugin.security.identity.oid.OIDPluginManager |
OIDPlugins.jar |
|
IBM DB2 Content Manager |
oracle.search.plugin.security.identity.icm.ICMIdentityPluginManager |
icm/ICMIdentityPlugin.jar |
|
Active Directory |
oracle.search.plugin.security.idm.IdentityPluginManagerADImpl |
idm/idmPlugin.jar |
|
Sun Java System Directory Server |
oracle.search.plugin.security.idm.IdentityPluginManagerIPlanetImpl |
idm/idmPlugin.jar |
|
OpenLDAP Directory |
oracle.search.plugin.security.idm.IdentityPluginManagerOpenLdapImpl |
idm/idmPlugin.jar |
|
Lotus Notes |
oracle.search.plugin.security.identity.ln.LNIdentityPluginManager |
ln/LNIdentityPlugin.jar |
The information Oracle SES saves from the identity plug-in (that is, the correspondence between names and canonical attribute values) may not be valid on different identity plug-ins. If you keep the same identity plug-in server (for example, to change port numbers or to switch to SSL), or if you use a new directory server that has identical user information, then you can deactivate and re-activate the identity plug-in anytime without restriction. This section describes steps you must perform if you change identity plug-in servers with user information that is not identical.
If you have sources using the ACL policy Oracle Secure Enterprise Search ACL and you decide to use a different identity plug-in server, then you must clear the ACL data before deactivating the original identity plug-in. If the ACL data is not cleared, then the ACL policy configured for that source while connected to the old identity plug-in server is not correctly enforced after connecting to the new identity plug-in server.
The existing ACL data can be cleared using either of these methods:
Before deactivating the identity plug-in, for each source using the ACL policy Oracle Secure Enterprise Search ACL, switch the ACL policy to No ACL. After connecting to the new identity plug-in server, restore the ACL policy to Oracle Secure Enterprise Search ACL and add the ACLs again. This temporarily makes the source public. If this is unacceptable, then use the next option.
Before deactivating the identity plug-in, delete each source that uses the ACL policy Oracle Secure Enterprise Search ACL. After connecting to the new identity plug-in server, add the sources back and configure them again. The documents are never made public; but this may involve more work than the previous option.
If you have sources using the ACL policy ACLs Controlled by the Source and you decide to use a different identity plug-in server, then after activating the new identity plug-in server, each source that uses this ACL policy must be re-crawled with the Process All Documents option. This forces the reloading and indexing of all of ACL information for such sources using the new identity plug-in server. Select the Process All Documents option on the Home - Schedules - Edit Schedule page.
Note:
If the ACL data is not cleared before switching identity plug-in servers, then you see a message that some users and groups could not be found by the identity plug-in. Those users and groups are still displayed on the Home - Sources -Authorization page. They can be deleted manually.The Oracle SES front-end interface collects user credentials, which are then validated against the active identity plug-in. In addition to authentication of search users, Oracle SES must also authenticate the crawler when accessing external data repositories. Administrators supply credentials to crawl private content through the following authentication methods:
HTML forms
OracleAS Single Sign-On
Oracle Access Manager (OAM) Single Sign-On
It is the administrator's responsibility to check the authorization policy to ensure that crawled documents are properly protected.
Oracle SES has two types of users:
Administrative User: The administrative user is eqsys. This user is natively defined in Oracle SES. Only this user can use the Oracle SES Administration GUI.
Search Users: Oracle SES lets you register an identity plug-in as an interface to any identity management system. (Oracle SES provides registered identity plug-ins for Oracle Internet Directory and other identity management systems.) The plug-in that you activate is responsible for all authentication and validation activity in Oracle SES. Use the Global Settings - Identity Management Setup page in the Oracle SES Administration GUI to associate Oracle SES with an identity management system.
Oracle Internet Directory is Oracle's native LDAP v3-compliant directory service. It is part of the Oracle Identity Management infrastructure. It is not included in Oracle SES. Oracle Internet Directory should be version 9.0.4 or 10.1.2 (with the latest patch release applied) for connection with Oracle SES. Oracle Internet Directory is not a part of Oracle SES, and therefore Oracle SES can be linked to any existing or new Oracle Internet Directory.
For the eqsys administrative user, a form login screen is available in the Oracle SES Administration GUI. This is the only way for an administrator to log in to Oracle SES.
For search users, there are three possible front-end authentication interfaces:
HTML form login page. Oracle SES provides an authentication page, and it authenticates against the identity plug-in.
Web Services API. The login and logout Web Services operations authenticate against the identity plug-in.
Single sign-on login screen. This can be made available by front-ending Oracle SES with OracleAS Single Sign-On and Oracle HTTP Server. These are available as part of the Oracle Identity Management infrastructure in OracleAS.
Note that whenever the public host name for the Oracle SES query application is different from the internal host name for Oracle SES, you must add a configuration parameter to search.properties. This is so that Oracle SES redirects the public host name to the internal host name. This situation arises when using a load balancer such as BIG-IP or using OracleAS Single Sign-on.
To add the configuration parameter, open ORACLE_HOME/search/webapp/config/search.properties in a text editor and add the ses.qapp.allowed_redirect_hosts parameter. The format is as shown:
ses.qapp.allowed_redirect_hosts=external_host1[, external_host2,...]
For example, if the internal URL for Oracle SES is ses.example.com:7777 and the external URL for the fronting Oracle HTTP Server (OHS) is ses_ext.example.com:8888, then you must add the following to search.properties:
ses.qapp.allowed_redirect_hosts=ses_ext.example.com
Note:
Only form login or single sign-on login can be used for search users at any point in time. Using single sign-on with the Web Services authentication interface is not supported.
Oracle strongly recommends that you SSL-protect the channel between the Oracle HTTP Server and the Oracle WebLogic server instance for secure content.