9 Using Remote Intradoc Client (RIDC)

This chapter describes how to initialize and use Remote Intradoc Client (RIDC), which provides a thin communication API for communication with Oracle Content Server.

This chapter includes the following sections:

• Section 9.1, "Introduction to RIDC"

• Section 9.2, "Initializing RIDC"

• Section 9.3, "Configuring Clients"

• Section 9.4, "Authenticating Users"

• Section 9.5, "Using Services"

• Section 9.6, "Handling Connections"

• Section 9.7, "Sending and Receiving Streams"

• Section 9.8, "Using RIDC Objects in JSP and JSPX Pages"

• Section 9.9, "Reusing Binders for Multiple Requests"

• Section 9.10, "Providing User Security"

• Section 9.11, "Configuring SSL Communication with Oracle Content Server"

• Section 9.12, "Using Tables for Content Items, the Search Index, and the File Store"

9.1 Introduction to RIDC

The RIDC communication API removes data abstractions to Oracle Content Server while still providing a wrapper to handle connection pooling, security, and protocol specifics. If you want to use a native Java API, then RIDC is recommended.

RIDC has these key features:

• Support is provided for Intradoc socket-based communication and the HTTP and JAX-WS protocols.

• Client configuration parameters include setting the socket time outs, connection pool size, and so forth.

• All calls to RIDC require some user identity for authentication. For Intradoc URLs, no credentials are required because the request is trusted between Oracle Content Server and the client. For HTTP URLs, the context requires credentials.

• To invoke a service, you can use the ServiceRequest object, which can be obtained from the client.

• The RIDC client pools connections, which requires that the caller of the code close resources when done with a response.

• Streams are sent to Oracle Content Server through the TransferStream interface.

• The RIDC objects follow the standard Java Collection paradigms, which makes them extremely easy to consume from a JSP/JSPX page.

• Binders can be reused among multiple requests.

• RIDC allows Secure Socket Layer (SSL) communication with Oracle Content Server.

9.1.1 RIDC Protocols

RIDC supports three protocols: Intradoc, HTTP, and WebServices/JAX-WS.

Intradoc: The Intradoc protocol communicates with Oracle Content Server over the Intradoc socket port (typically, 4444). This protocol does not perform password validation and so requires a trusted connection between the client and Oracle Content Server. Clients that use this protocol are expected to perform any required authentication. Intradoc communication can also be configured to run over SSL.

HTTP: RIDC communicates with the web server for Oracle Content Server using the Apache HttpClient package. Unlike Intradoc, this protocol requires authentication credentials for each request.

For more information, see the Jakarta Commons HttpClient documentation on the HttpClient Home page of the Apache HttpClient web site at

http://hc.apache.org/httpclient-3.x

JAX-WS: The JAX-WS protocol is supported only in Oracle UCM 11g with Oracle Content Server running in Oracle WebLogic Server. To provide JAX-WS support, several additional JAR archives are required. These JAR archives are provided with the ecm-client.zip distribution, which is available from the Oracle Technology Network (OTN).

These additional JAR archives are required for JAX-WS support:

• oracle.webservices.standalone.client.jar

• wseeclient.jar

• jps-az-api.jar

These JAR archives should be placed in the /src/lib/jaxws subdirectory of the RIDC installation directory.

9.1.2 SSL Communication

RIDC allows Secure Socket Layer (SSL) communication with Oracle Content Server using the Intradoc communication protocol.

Note:

You must install and enable the SecurityProviders component in the Oracle Content Server instance that you want to access, and you must configure Oracle Content Server for SSL communication.

An example of using the IDC protocol over a secure socket (SSL) follows:

// build a secure IDC client as cast to specific type
IntradocClient idcClient = (IntradocClient
   manager.createClient("idcs://localhost:54444");

// set the SSL socket options
config.setKeystoreFile("ketstore/client_keystore");  //location of keystore file
config.setKeystorePassword ("password");      // keystore password
config.setKeystoreAlias("SecureClient");  //keystore alias
config.setKeystoreAliasPassword("password");  //password for keystore alias

For more information, see Section 9.11, "Configuring SSL Communication with Oracle Content Server."

9.1.3 MBeans Implementation

RIDC provides an MBeans implementation allowing administrators to change properties of an RIDC connection at runtime using JMX and MBeans.

To register and enable MBeans, add the following to your code:

import oracle.stellent.ridc.convenience.adf.mbeans.IdcMBeanManager;
...
//connection name is the connection in the ADFContext you want to manage
IdcMBeanManager mbeanManager = IdcMBeanManager.getInstance(connectionName);
mbeanManager.register();

Once the application has started, edit the connection using a tool such as JConsole to connect to your application and change connection information while the application is running.

9.2 Initializing RIDC

To initialize RIDC, you will need the ECM Client libraries, which are shipped with the RIDC distribution, in your class path.

For the JAX-WS protocol, you also need to configure Oracle WebLogic Server security for the Oracle UCM web services. The security configuration includes these tasks:

• Setting up the policy for the login service

• Creating a new keystore file (or adding credentials to your existing keystore), which will be used by both the server and the client

• Setting up an Oracle wallet by adding the credentials

The client requires the following items:

• The JPS configuration file

• The keystore

• The Oracle wallet from the server

For information about configuring the server and client for web services, see the Oracle Fusion Middleware Services Reference Guide for Oracle Universal Content Management.

The following table shows the URL formats that are supported.

URL	Description
http://host/cs/idcplg	URL to the Oracle Content Server CGI path.
https://host/cs/idcplg	Uses SSL over HTTP; requires extra configuration to load the SSL certificates.
idc://host:4444	Uses the Intradoc port; requires only the hostname and the port number.
idcs://host:4444	Uses SSL over the Intradoc port; requires extra configuration to load the SSL certificates.
http://wlsserver:7044/idcnativews	Uses the JAX-WS protocol to connect to Oracle Content Server.

This example code initializes RIDC for an Intradoc connection:

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the intradoc protocol
IdcClient idcClient = manager.createClient("idc://localhost:4444");

This example code initializes an HTTP connection (the only difference from an Intradoc connection is the URL):

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the HTTP protocol
IdcClient idcClient = manager.createClient("http://localhost/idc/idcplg");

This example code initializes a JAX-WS client. These two web services are exposed by Oracle Content Server: the login service and the request service. You will need the web context root that these web services use. By default, this is idcnativews.

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the JAXWS protocol
IdcClient idcClient = manager.createClient("http://wlsserver:7044/idcnativews");

9.3 Configuring Clients

Configuration of the clients can be done after they are created. Configuration parameters include setting the socket time outs, connection pool size, and so on. The configuration is specific to the protocol; if you cast the IdcClient object to the specific type, then you can retrieve the protocol configuration object for that type.

This example code sets the socket time out and wait time for Intradoc connections:

// build a client as cast to specific type
IntradocClient idcClient = (IntradocClient)manager.createClient
   ("http://host/cs/idcplg");

// get the config object and set properties
idcClient.getConfig ().setSocketTimeout (30000); // 30 seconds
idcClient.getConfig ().setConnectionSize (20);   // 20 connections

These JAX-WS specific configurations can be set after you have created the client:

// build a client as a cast for jaxws type
JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient(
   ("http://wlsserver:7044/idcnativews");
JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();

You can set the name of the Oracle Content Server instance that you want to connect to. By default, this is /cs/, which is the default web context for an Oracle UCM installation. If the server web context is different than the default, then you can set the the web context by editing a property. This example code sets your web context root:

// set the property
jaxwsConfig.setServerInstanceName("/mywebcontext/");

A JPS configuration file is required for most policies, such SAML or Message Token. This example code sets the location of the JPS configuration file:

jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");

This example code sets the security policy:

jaxwsConfig.setClientSecurityPolicy
   ("policy:oracle/wss11_username_token_with_message_protection_client_policy");

RIDC uses the default values for the installed web services. If, for some reason, the web services have been modified and do not conform to the default URIs or URLs, you may need to modify the default values. This example code changes the login and request service URLs:

// login port wsdl url
jaxwsConfig.setLoginServiceWSDLUrl(new URL
   ("http://server:7044/webservices/loginPort?WSDL"));

//request port wsdl url
jaxwsConfig.setRequestServiceWSDLUrl(new URL
   ("http://server:7044/anotherservice/myrequestport?WSDL"));

The default streaming chunk size is set to 8192. This example code changes the streaming chunk size:

jaxwsConfig.setStreamingChunkSize(8190);

9.4 Authenticating Users

All calls to RIDC require some user identity. Optionally, this identity can be accompanied by credentials as required by the protocol. The user identity is represented by the IdcContext object; once created, it can be reused for all subsequent calls. To create an identity, you pass in the user name and, optionally, some credentials:

//create a simple identity with no password (for idc:// urls)
IdcContext userContext = new IdcContext("sysadmin");

// create an identity with a password
IdcContext userPasswordContext = new IdcContext("sysadmin", "idc");

For Intradoc URLs, you do not need any credentials because the request is trusted between Oracle Content Server and the client.

For HTTP and JAX-WS URLs, the context needs credentials.

For HTTP URLs, the credentials can be a simple password or anything that the HttpClient package supports.

For JAX-WS URLs, the requirement for credentials will be dependent on the service policy that the web service is configured to use by the server.

9.5 Using Services

To invoke a service, use the ServiceRequest object, which you can obtain from the client. Creating a new request will also create a new binder and set the service name in the binder, along with any other default parameters. From that point, you can populate the binder as needed for the request.

This example code executes a service request and gets back a DataBinder object with the results:

// get the binder
DataBinder binder = idcClient.createBinder();

// populate the binder with the parameters
binder.putLocal ("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal ("QueryText", "");
binder.putLocal ("ResultCount", "20");

// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// get the binder
DataBinder serverBinder = response.getResponseAsBinder ();

The ServiceResponse object contains the response from Oracle Content Server. From the response, you can access the stream from Oracle Content Server directly, or you can parse it into a DataBinder object and query the results.

This example code takes a ServiceResponse and gets the search results, printing out the title and author values:

// get the binder
DataBinder binder = response.getResponseAsBinder ();
DataResultSet resultSet = binder.getResultSet ("SearchResults");

// loop over the results
for (DataObject dataObject : resultSet.getRows ()) {
    System.out.println ("Title is: " + dataObject.get ("dDocTitle"));
    System.out.println ("Author is: " + dataObject.get ("dDocAuthor"));
}

9.6 Handling Connections

The RIDC client pools connections, meaning that the caller of the code must close resources when it is done with a response. This is done by calling getResponseAsBinder, which closes resources automatically, or by calling close on the stream returned from a call to getResponseStream. If you do not want to examine the results, close must still be called, either by getting the stream and closing it directly or by calling close on the ServiceResponse object.

9.6.1 Closing Resources

The following examples show how to use the options for closing resources.

To close resources through getResponseAsBinder:

// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// get a binder closes the response automatically
response.getResponseAsBinder ();

To close resources by closing the stream:

// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// get the result stream and read it
InputStream stream = response.getResponseStream ();
int read = 0;
while ((read = stream.read ()) != -1)
{
}

//close the stream
stream.close ();

To close resources by calling the close method on the ServiceResponse object:

// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// close the response (which closes the stream directly)
response.close ();

9.6.2 Handling Connection Pooling

The IdcClientConfig#getConnectionPool property determines how RIDC will handle the pooling of connections. There are two options, pool and simple.

• Pool is the default, and it means to use an internal pool that allows a configurable number of active connections at a time (configurable via the IdcClientConfig#getConnectionSize property), with the default active size set to 20.

• Simple does not enforce a connection maximum and rather lets every connection proceed without blocking.

You can register a different pool implementation through the IdcClientManager#getConnectionPoolManager()#registerPool() method, which maps a name to an implementation of the ConnectionPool interface. Then you can use the name in the IdcClientConfig object to select that pool for a particular client.

9.7 Sending and Receiving Streams

Streams are sent to Oracle Content Server through the TransferStream interface. This interface wraps the actual stream with metadata about the stream (length, name, and so on).

This example code performs a check-in to Oracle Content Server:

// create request
DataBinder binder = idcClient.createBinder();
binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL");

// get the binder
binder.putLocal ("dDocTitle", "Test File");
binder.putLocal ("dDocName", "test-checkin-6");
binder.putLocal ("dDocType", "ADACCT");
binder.putLocal ("dSecurityGroup", "Public");

// add a file
binder.addFile ("primaryFile", new TransferFile ("test.doc"));

// check in the file
idcClient.sendRequest (userContext, binder);

You can receive a stream from Oracle Content Server through the ServiceResponse object; the response is not converted into a DataBinder object unless you specifically request it. If you just want the raw HDA data, you can get that directly, along with converting the response to a String or DataBinder object:

// create request
DataBinder binder = idcClient.createBinder ();

// execute the service
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// get the response stream
InputStream stream = response.getResponseStream ();

// get the response as a string
String responseString = response.getResponseAsString ();

// parse into data binder
DataBinder dataBinder = response.getResponseAsBinder ();

9.8 Using RIDC Objects in JSP and JSPX Pages

The RIDC objects all follow the standard Java Collection paradigms, which makes them extremely easy to consume from a JSP or JSPX page. Assume the ServerResponse object (used in the previous example) was available in the HttpServletRequest object in an attribute called idcResponse. This example JSPX code will iterate over the response and create a small table of data:

<table>
  <tr>
    <th>Title</th>
    <th>Author</th>
    <th>Release Date</th>
  </tr>
<c:forEach var="row" items="${idcResponse.dataBinder.SearchResults.rows}">
  <tr>
    <td>${row.dDocTitle}</td>
    <td>${row.dDocAuthor}</td>
    <td>${row.dInDate}</td>
   </tr>
</c:forEach>
</table>

9.9 Reusing Binders for Multiple Requests

The binders can be reused among multiple requests. A binder from one request can be sent in to another request. For example, this example code pages the search results by reusing the same binder for multiple calls to Oracle Content Server:

// create the user context
IdcContext idcContext = new IdcContext ("sysadmin", "idc");

// build the search request binder
DataBinder binder = idcClient.createBinder();
binder.putLocal("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal("QueryText", "");
binder.putLocal("ResultCount", "20");

// send the initial request
ServiceResponse response = idcClient.sendRequest (binder, idcContext);
DataBinder responseBinder = response.getResponseAsBinder();

// get the next page
binder.putLocal("StartRow", "21");
response = idcConnection.executeRequest(idcContext, binder);
responseBinder = response.getResponseAsBinder();

// get the next page
binder.putLocal("StartRow", "41");
response = idcConnection.executeRequest(binder, idcContext);
responseBinder = response.getResponseAsBinder();

9.10 Providing User Security

Oracle UCM has several security models that are controlled by settings in Oracle Content Server. To resolve if a particular user has access to a document, three things are needed: the user's permission controls, the document's permission controls, and the Oracle Content Server security environment settings.

It is assumed that the application program calling the UserSecurity module will fetch documents and the DOC_INFO metadata (in the document's binder, typically the result of a search) as some superuser and cache this information. When the application needs to know if a particular user has access to the document, a call is made to Oracle Content Server as that user to fetch that user's permissions. Once the user's permission controls are known, then they can be matched to the information in the document's metadata to resolve the access level for that user. The available access levels follow:

• READ

• READ/WRITE

• READ/WRITE/DELETE

• READ/WRITE/DELETE/ADMIN

It is preferable to reduce the number of calls to Oracle Content Server (using a cache) and to provide a default implementation for matching the user's permissions information with the document's permission information. One limitation is that Oracle Content Server controls which types of security are used in some server environment properties: UseAccounts=true and UseCollaboration=true.

The user security convenience is accessed through the IUserSecurityCache interface. Three concrete classes implement the optional Oracle Content Server security:

• The UserSecurityGroupsCache class simply keeps a cache of user permissions and will match documents considering only Security Group information.

• The UserSGAccountsCache class adds a resolver to also consider Account information if Oracle Content Server has the UseAccounts=true setting.

• The UserSGAcctAclCache class adds a resolver to also consider ACL permissions if UseCollaboration=true.

The IAccessResolver interface allows the addition of classes that can participate in the resolution of the access levels for a document.

This example code uses the three classes for implementing security:

IdcClientManager m_clientManager = new IdcClientManager ();
IdcClient m_client = m_clientManager.createClient
   ("http://localhost/scs/idcplg");

//RIDC superuser context
IdcContext m_superuser = new IdcContext("sysadmin", "idc");

//Examples of the three concrete cache classes
IUserSecurityCache m_SGCache = new UserSecurityGroupsCache 
   (m_client, 20, 1000);
IUserSecurityCache m_SGAcctCache = new UserSGAccountsCache 
   (m_client, 20, 1000, 20000);
IUserSecurityCache m_SGAcctAclCache = new UserSGAcctAclCache 
   (m_client, 20, 1000, 20000, m_superuser);

//Example test
testDocPermission () {
   DataBinder m_doc1 = getDataBinder ("TEST");

   //Get the document information (typically in the first row of DOC_INFO)
   DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0);

   //Get the cache id for this user
      //Important: this makes a live call to Oracle Content Server
      //to get the user ID for "Acme1")
      //CacheId acme1 = m_SGAcctAclCache.getCacheIdForUser 
                                      //   (new IdcContext("Acme1", "idc"));
      //You may want to include this:

   IdcContext context = new IdcContext("Acme1", "idc");
   CacheId acme1 = new CacheId (context.getUser (), context);

   //Get the access level for this document by this user
int access = m_SGAcctAclCache.getAccessLevelForDocument (acme1, docInfo);
   }

//Example code to get a Document's DOC_INFO databinder
DataBinder getDataBinder (String dDocName) throws IdcClientException {
   DataBinder dataBinder = m_client.createBinder ();
   dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME");
   dataBinder.putLocal ("dDocName", dDocName); 

   ServiceResponse response = m_client.sendRequest 
      (m_superuser, dataBinder);
   return response.getResponseAsBinder ();
}

//Example code to create a DataObject
DataObject dataObject = m_client.getDataFactory ().createDataObject ();
dataObject.put ("dSecurityGroup", "public");
dataObject.put ("dDocAccount", "Eng/Acme");

Internally, these fields from the document are examined during getAccessLevelForDocument() processing:

• For the AccessResolverSecurityGroups class: dSecurityGroup

• For the AccessResolverAccounts class: dDocAccount

• For the AccessResolverSecurityGroups class: xClbraUserList and xClbraAliasList

The preceding IAccessResolver classes determine if they should participate based on cached information from Oracle Content Server. If they do participate, the access levels are put together with the AND operator.

9.11 Configuring SSL Communication with Oracle Content Server

RIDC allows Secure Socket Layer (SSL) communication with Oracle Content Server. This section provides basic information about SSL communication, including how to set up a sample implementation for testing purposes.

For SSL communication, you must install and enable the SecurityProviders component, configure Oracle Content Server with a new incoming provider, and specify the truststore or keystore information. You must have a valid keystore or trust manager with signed, trusted certificates on both the client and Oracle Content Server.

The sample implementation uses a JDK utility to create a self-signed key pair and certificates. Oracle does not provide signed certificates. For most implementations, you will want a certificate signed by a universally recognized Certificate Authority.

The following subsections describe how to configure SSL communication with Oracle Content Server:

• Section 9.11.1, "Installing and Enabling the SecurityProviders Component"

• Section 9.11.2, "Configuring an Incoming Provider for SSL Communication"

• Section 9.11.3, "Creating Self-Signed Key Pairs and Certificates"

9.11.1 Installing and Enabling the SecurityProviders Component

You must install and enable the SecurityProviders component in the Oracle Content Server instance you want to access. This component is installed and enabled by default in Oracle Content Server 11gR1.

In Oracle Content Server 10gR3, you need to install and enable the component manually. For information about installing and enabling components, see the Oracle UCM 10gR3 installation documentation.

9.11.2 Configuring an Incoming Provider for SSL Communication

You can set up a new keepalive incoming socket provider or a new SSL incoming socket provider. The setup steps for both providers follow. Using keepalive improves the performance of a session and is recommended for most implementations.

To set up a new incoming provider:

1. Log in to Oracle Content Server as an administrator.

2. Click Administration and then Providers.

   Figure 9-1 List of Providers in Oracle Content Server

   
   Description of "Figure 9-1 List of Providers in Oracle Content Server"
   
   

3. Click Add for the sslincoming provider.

   The Add Incoming Provider page opens.

4. Enter a provider name and description.

5. Enter an open server port.

6. Enter configuration information for either a new SSL keepalive incoming socket provider or a new SSL incoming socket provider. The setup steps for both providers are listed in the following text. Using keepalive improves the performance of a session and is recommended for most implementations.

   SSL keepalive incoming socket provider

   • Provider Class: idc.provider.ssl.SSLSocketIncomingProvider

   • Connection Class: idc.provider.KeepaliveSocketIncomingConnection

   • Server Thread Class: idc.server.KeepaliveIdcServerThread

   SSL incoming socket provider

   • Provider Class: idc.provider.ssl.SSLSocketIncomingProvider

   • Connection Class: intradoc.provider.SocketIncomingConnection

   • Server Thread Class: intradoc.server.IdcServerThread

7. Click Add.

After you have completed setting up a new incoming provider, you must also specify truststore and keystore information.

9.11.3 Creating Self-Signed Key Pairs and Certificates

For most implementations, you will want a certificate signed by a universally recognized Certificate Authority. However, if you control both the client and server and want only to ensure that your transmissions are not intercepted, or if you are simply testing your implementation, you can create your own self-signed key pairs and certificates by using the JDK utility called keytool.

Key and Certificate Management Tool (keytool) is a key and certificate management utility that enables users to administer their own public and private key pairs and associated certificates for use in self-authentication. It is provided as part of the Sun JDK. Keytool is a command-line utility. The executable is located in the bin subdirectory.

9.11.3.1 Creating the Client and Server Keys

From a command-line prompt, navigate to the JDK-Home/bin subdirectory, and issue the -genkey command. This command generates a new key and takes several arguments. The arguments in the following table are used with this command.

Argument	Description
-alias	Alias of the key being created. This is the way a keystore knows which element in the file you are referring to when you perform operations on it.
-keyalg	Encryption algorithm to use for the key.
-keystore	Name of the binary output file for the keystore.
-dname	Distinguished name that identifies the key.
-keypass	Password for the key that is being generated.
-storepass	Password used to control access to the keystore.

Generate a separate key pair for both the client and the server. To do this, you will need to run the -genkey command twice, each time placing the key pair into a separate keystore.

You will need to specify the alias, the algorithm to use, the keystore name, the distinguished name, and passwords for the keys and the keystore. This example uses RSA as the algorithm and idcidc as the password for the key and the keystore.

Use these argument values for the client:

• -alias SecureClient

• -keyalg RSA

• -keystore client_keystore

• -dname "cn=SecureClient"

• -keypass idcidc

• -storepass idcidc

# keytool -genkey -alias SecureClient -keyalg RSA -keystore client_keystore -dname "cn=SecureClient" -keypass idcidc -storepass idcidc

Use these argument values for the server:

• -alias SecureServer

• -keyalg RSA

• -keystore server_keystore

• -dname "cn=SecureServer"

• -keypass idcidc

• -storepass idcidc

# keytool -genkey -alias SecureClient -keyalg RSA -keystore client_keystore -dname "cn=SecureClient" -keypass idcidc -storepass idcidc

# keytool -genkey -alias SecureServer -keyalg RSA -keystore server_keystore -dname "cn=SecureServer" -keypass idcidc -storepass idcidc

Each of these commands will generate a key pair wrapped in a self-signed certificate and stored in a single-element certificate chain.

9.11.3.2 Self-Signing the Certificates

Keys are unusable unless they are signed. The keytool utility will self-sign them for you so that you can use the certificates for internal testing. However, these keys are not signed for general use.

From a command line prompt, issue the -selfcert command (this command self-signs your certificates and takes several arguments). Run the -selfcert command twice, once for the client and again for the server.

Use these argument values for the client:

• -alias SecureClient

• -keystore client_keystore

• -keypass idcidc

• -storepass idcidc

Use these argument values for the server:

• -alias SecureServer

• -keystore server_keystore

• -keypass idcidc

• -storepass idcid

Examples of -selfcert commands follow:

# keytool -selfcert -alias SecureClient -keystore client_keystore -keypass idcidc -storepass idcidc

# keytool -selfcert -alias SecureServer -keystore server_keystore -keypass idcidc -storepass idcidc

The certificate is now signed by its private and public key, resulting in a single-element certificate chain. This replaces the one that you generated previously.

9.11.3.3 Exporting the Certificates

After you have created the client and server keys and self-signed the certificates, you now have two key pairs (public and private keys) in two certificates locked in two keystores. Since each application will need to have the public key of the other to encrypt and decrypt data, you need to place a copy of each public key in the other application's keystore.

From a command-line prompt, issue the -export command (this command exports your certificates and takes several arguments). Run the -export command twice, once for the client and again for the server. Use the -file argument to redirect the output to a file instead of the console.

Use these argument values for the client:

• -alias SecureClient

• -file client_cert

• -keystore client_keystore

• -storepass idcidc

Use these argument values for the server:

• -alias SecureServer

• -file server_cert

• -keystore server_keystore

• -storepass idcidc

Examples of -export commands follow:

# keytool -export -alias SecureClient -file client_cert -keystore client_keystore -storepass idcidc

(Certificate stored in the file client_cert)

# keytool -export -alias SecureServer -file server_cert -keystore server_keystore -storepass idcidc

(Certificate stored in the file server_cert)

The certificate (containing the public key and signer information) has now been exported to a binary certificate file.

9.11.3.4 Importing the Certificates

The final step in setting up your self-signed certificates is to import the public certificates of each program into the keystore of the other. Keytool will present you with the details of the certificates you are requesting to be imported and provide a request confirmation.

From a command line prompt, issue the -import command (this command imports your certificates and takes several arguments). Run the -import command twice, once for the client and again for the server. Notice that the -keystore values are reversed.

Use these argument values for the client:

• -alias SecureClient

• -file client_cert

• -keystore server_keystore

• -storepass idcidc

Use these argument values for the server:

• -alias SecureServer

• -file server_cert

• -keystore client_keystore

• -storepass idcidc

Examples of -import commands follow:

# keytool -import -alias SecureClient -file client_cert -keystore server_keystore -storepass idcidc

Owner: CN=SecureClient
Issuer: CN=SecureClient
Serial number: 3c42e605
Valid from: Mon Jan 14 08:07:01 CST 2002 until: Sun Apr 14 09:07:01 CDT 2002
Certificate fingerprints:
  MD5: 17:51:83:84:36:D2:23:A2:8D:91:B7:14:84:93:3C:FF
  SHA1: 61:8F:00:E6:E7:4B:64:53:B4:6B:95:F3:B7:DF:56:D3:4A:09:A8:FF
Trust this certificate? [no]: y
Certificate was added to keystore

# keytool -import -alias SecureServer -file server_cert -keystore client_keystore -storepass idcidc

Owner: CN=SecureServer
Issuer: CN=SecureServer
Serial number: 3c42e61e
Valid from: Mon Jan 14 08:07:26 CST 2002 until: Sun Apr 14 09:07:26 CDT 2002
Certificate fingerprints:
  MD5: 43:2F:7D:B6:A7:D3:AE:A7:2E:21:7C:C4:52:49:42:B1
  SHA1: ED:B3:BB:62:2E:4F:D3:78:B9:62:3B:52:08:15:8E:B3:5A:31:23:6C
Trust this certificate? [no]: y
Certificate was added to keystore

The certificates of each program have now been imported into the keystore of the other.

9.12 Using Tables for Content Items, the Search Index, and the File Store

The following subsections describe how to search tables for information about content items:

• Section 9.12.1, "Finding Information for Each Content Item"

• Section 9.12.2, "Using a Search Index"

• Section 9.12.3, "Using the File Store Provider"

9.12.1 Finding Information for Each Content Item

Content managed by Oracle Content Server is primarily tracked by four tables:

• Revisions

• Documents

• DocMeta

• RevClasses

These tables track the content's metadata, state, and actions as well as information that is associated with each file.

Revisions

This table tracks core information about each revision of the content:

• One row per revision

• Different revisions with the same content that share the same content ID and RevClass ID

• System metadata for each revision:

  • Metadata for revisions: content ID, title, author, check-in date, and so on

  • Metadata for categorization and security: type, security group, doc account

• State information for various actions:

  • Indexing

  • Workflow

  • Document conversion

• Numeric IDs and text labels to help track and retrieve a revision:

  • A unique dID value for each revision (the primary key in the table)

  • A unique dRevClassID value for the content

  • A revision ID to mark the revision number for each revision

Documents

This table tracks information for files that are associated with each content revision.

• One row per revision

• Multiple rows per revision, with one row for each of these files:

  • Primary

  • Alternate

  • Web-viewable

• File information: original name, location, language, size, and so on

DocMeta

This table contains extended metadata fields:

• One row for each revision

• One column for each metadata field

• Definition of each field, stored in the DocMetaDefinition table

RevClasses

This table tracks information for each content revision:

• One row per content item

• Row locked for content modification

• Unique dDocName and RevClassId values

• Current indexed revision

• Dates and users:

  • Creation date and creator

  • Last modified date and user

  • Owner

9.12.2 Using a Search Index

Oracle Content Server provides various ways to search the repository. Metadata searches can be based on the Revisions, Documents, DocMeta, and RevClasses tables. To efficiently perform text searches, the full-text search feature of Oracle Database can be utilized, and the IdcText table can be created to hold the search index.

IdcText

This table contains selected columns from the Revisions, Documents, DocMeta, and RevClasses tables as well as columns for other data:

• It contains a predefined list from the Revisions, RevClasses, and Documents tables.

• It contains custom metadata that is indicated as searchable from the DocMeta table.

• The OtsMeta column (CLOB field) contains an SDATA section and additional indexable fields that are not in the other columns. However, SDATA has significant limitations.

  The SDATA section has significant limitations.

• The OtsContent column contains an indexable document.

• The ResultSetInterface column can be used for sorting or count estimation, or to drill down.

9.12.3 Using the File Store Provider

The File Store Provider can be used to distribute files managed by Oracle Content Server on the file system, a database, other devices, or any combination of these. The files are stored in SecureFiles in Oracle Content Server 11g. For database-backed file storage, the FileStorage and FileCache tables store the information related to each file.

FileStorage

This table stores file information and some additional information:

• File stored in a BLOB field (SecureFiles in Oracle Content Server 11g)

  The database administrator can turn on additional BLOB optimizations. For example, deduplication, compression, and encryption with SecureFiles.

• Values for dID and dRenditionID that point to a particular file managed by Oracle Content Server

• Tracking information in a small number of fields: last modified date and file size

FileCache

This table stores pointers for files cached on the file system, for certain types of processing (extraction, conversion, and so on), and for quick access by the web server. This pointer is also used to perform cleanup.