This section covers these topics:
A provider is an Application Programming Interface (API) that establishes connection to outside entities. These entities can be:
Oracle WebLogic Server instances
LDAP servers
databases
server sockets
file store system
Inbound Refinery
By default, a Content Server instance has three system providers:
In addition, you can create the following types of providers:
Outgoing: A connection initiated to an outside entity. You can use this type to communicate between Content Server instances. If you want to use SSL with an outgoing provider, see details in "Security Providers".
Database: An information repository server that provides an API for connecting and communicating with it. This retrieves information and enables information to be changed in the database. Examples of this type are system databases.
Incoming: A connection initiated from an outside entity like a browser or client application. The provider listens on a specified port to be aware of incoming connections. If you want to use SSL with an incoming provider, see details in "Security Providers".
Preview: An outgoing provider connection to Oracle Content Publisher, for use with the optional HTML Preview feature.
LDAP: A connection initiated to an LDAP (Lightweight Directory Access Protocol) server for managing external user access to the content server. This type of provider is supported by the ActiveDirectoryLdap component, which is installed (disabled) by default during Content Server installation. As of 11g Release 1 (11.1.1) its functionality is mostly superseded by JpsUserProvider, in particular for nested group support.
HTTP: A connection that allows communication between Content Servers using the HTTP protocol. This type of provider requires the Proxy Credentials Extension component, which is installed (enabled) by default during Content Server installation.
JpsUserProvider: A connection to an Oracle WebLogic Server instance. This provider uses Java Platform Security (JPS) to perform user authentication, user authorization, and retrieval of user metadata through an Oracle WebLogic Server. This type of provider is supported by the JpsUserProvider component, which is installed (enabled) by default with Content Server.
The different types of providers described in the previous section are added under specific circumstances to work with various other Oracle products or utilities. The following subsections describe those conditions and the particular provider types that must be added in each scenario.
Outgoing providers are added to use the Content Server Archiver utility and Inbound Refinery. If you want to use SSL or keepalive with an outgoing provider, see details in "Security Providers".
Archiver Utility (Content Server): The Archiver is a utility within the core Content Server product that enables system administrators to copy and remove content and store it for future use. Users can query a set of content from the Content Server instance and export it to an archive. Archives can then be imported to other Content Server instances or can be imported back to the same instance with changed metadata fields.
An outgoing provider is required to use the Archiver Transfer feature, which is used to archive content across a firewall or between two systems that do not share a file system. For additional information about the Transfer feature, the different types of transfers and the outgoing provider requirements, see the Managing Migration chapter for more information.
For additional reference information about outgoing providers and each specific field, see "Outgoing Provider Page".
Inbound Refinery: The Inbound Refinery server processes content checked in to Content Server and converts it to specified formats. An outgoing connection to the Inbound Refinery server is necessary for communication with Content Server. For details, see Oracle Fusion Middleware Administrator's Guide for Conversion.
Database providers are added to use external databases.
Frequently, it is desirable or necessary to perform database queries on databases that are not the default Content Server database. In this case, customized database providers can be created that make it possible to access any data from any application, regardless of which database management system is handling the data. Using customized database providers to integrate external databases into a Content Server system, search results can be combined and viewed on a single search screen. Additionally, data can be imported from these external database sources.
Administrators can create a database provider in one of two methods:
Use the Oracle WebLogic Server Administration Console to create an Oracle WebLogic Server data source to the database, then configure a Content Server database provider to use that data source. For information, see "Creating a JDBC Data Source for a WebLogic Domain Server" in Oracle Fusion Middleware Developer's Guide for Oracle Application Development Framework.
Create a Content Server database provider to connect directly to the database through a JDBC connection, without using an Oracle WebLogic Server data source. This mode is provided for instances with pre-existing connections in their configurations.
For additional reference information about Content Server database providers and each specific field, see "Database Provider Page".
Consulting Services is required to perform this operation.
Incoming providers are added to use WebDAV support and the Content Server Archiver utility. If you want to use SSL or keepalive with an incoming provider, see details in "Security Providers".
Oracle WebDAV Support: With version 6.2 of Content Server, you could implement WebDAV (Web-Based Distributed Authoring and Versioning) support using an incoming provider and the Content Server integrated Tomcat servlet engine. In Content Server version 7.0 and later, however, WebDAV support is provided by a custom feature, so the provider and servlet engine are no longer necessary.
See the Oracle Fusion Middleware Applications Administrator's Guide for Content Server for more information.
Archiver Utility (Content Server): The Archiver is a utility within the core Content Server product that enables system administrators to copy and remove content and store it for future use. Users can query a set of content from the Content Server instance and export, import, or replicate to another instance, or change metadata fields. Tasks most frequently performed involve transfer, backup, and reorganization of information within the system.
Generally, when data or content items are moved from one repository to another, the Archiver utility uses a push technology to relocate the files. However, occasionally your system might require that the files be pulled rather than pushed. In this case, an incoming provider must be created. For additional reference information about incoming providers and each specific field, see "Incoming Provider Page".
Consulting Services are required perform this operation.
Preview providers are added to use HTML Preview and Content Categorizer.
HTML Preview: HTML Preview is a feature that provides users with instant feedback on how their content will display on the published Web site. This feature enables users to modify the original content before it is actually checked in. HTML Preview also helps users ensure that correct metadata has been assigned to the content. During the installation process, a preview provider must be created. For additional overview and installation information about HTML Preview, see the Oracle Fusion Middleware Application Administrator's Guide for Content Server.
Content Categorizer: Content Categorizer suggests metadata values for documents being checked into Content Server or for existing documents that need to have metadata reapplied. For Content Categorizer to recognize structural properties of a document, the file must be converted to XML.
If you are using Content Publisher to set up a template for the required XML conversion process, the HTML Preview feature must be configured as a preview provider. (HTML Preview is a feature that enables users to preview their content and see what the converted output from Content Publisher will look like.)
For more general overview, reference, pre-installation tasks and considerations, and complete installation information about Content Categorizer, see the Oracle Fusion Middleware Administrator's Guide for Content Categorizer. This guide provides relevant information about any additional products that may be required or are optional. For additional reference information about preview providers and each specific field, see "Preview Provider Page".
Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs over TCP/IP. It provides high-level functionality to manage resources within a network and works with Content Server to manage security and user authentication. The LDAP directory service model is based on a collection of attributes and is used to access information stored in an information directory. As such, LDAP is used to validate a set of user name and password credentials against an authentication source. This process will grant privileges to a user to give them access to Web resources.
An LDAP server provides a single source for user-related information that can be accessed from applications such as Content Server and other Oracle product modules. Instead of maintaining user information within Content Server, you can integrate an LDAP directory to authenticate user credentials to the Content Server instance.
Note:
As of 11g Release 1 (11.1.1), LDAP provider functionality is superseded by JpsUserProvider. Use of the LDAP provider is not recommended. See "When to Add a JPS User Provider".If you decide to use an LDAP server (other than Active Directory, which can be integrated directly with the Content Server), you must create an LDAP provider to set up communication between the Content Server instance and the LDAP server. When properly configured, the LDAP provider authorizes external users through the mapping properties that are linked to role assignments and account permissions (defined on the Ldap Provider page).
For additional reference information about LDAP providers and each specific field, see "LDAP Provider Page".
Although not required, you are encouraged to have Consulting Services assist you with creating an LDAP security model and deploying the LDAP integration. Contact your sales representative for more information.
LDAP integration is also useful with the following content management products and architectures:
Portlets on WebSphere: WebSphere users can access Content Server through the Oracle Content Integration Suite. This portal interface enables users and developers to retrieve, view, and download Content Server content items based on full text or metadata search queries. When using the Content Integration Suite, the WebSphere Application Server is recommended. If you are using a WebSphere Portal Server, the Oracle Content Portal Suite is a recommended addition to the Content Integration Suite.
The Content Integration Suite connects directly to the Content Server instead of the database. This direct connection avoids the authentication step at the Web server and enables the developer total control over the authentication and authorization of users. The advantage is you can authenticate users at the Content Integration Suite layer however you want. You can integrate with an LDAP server at the application server level, or you can ask the Content Server to validate the passwords for you.
For more information about using WebSphere with the Content Integration Suite and the Content Portal Suite, see the documentation provided with the WebSphere Portal Server, WebSphere Application Server, Oracle Content Integration Suite, and Oracle Content Portal Suite.
Content Tracker: Content Tracker is a system that is built from a collection of software features that, when combined, enable users to use a standard browser to track content usage through an integrated set of analytical tools. The data provided by the Content Server is derived from logged data that includes Web server log data, Content Server data, and user information. Content Tracker accesses this data, performs analysis on it, and produces descriptive reports. Integrating an LDAP directory server with Content Tracker is optional. However, if LDAP is used, an LDAP provider must be created.
For more information about the related data repositories, report generation, producing queries and installation procedures, see the Oracle Fusion Middleware Application Administrator's Guide for Content Server.
JpsUserProvider connects to an Oracle WebLogic Server instance and supports the Oracle WebLogic Server authentication mechanism (Basic, Form, Single Sign On, WNA, and so forth). Java Platform Security (JPS) provides a uniform interface for authenticating and authorizing users from Oracle Fusion Middleware applications regardless of the back-end user storage (XML, LDAP, database, Active Directory, and so on). JPS API calls are used to perform user authentication, user authorization and retrieval of user metadata.
Note:
As of 11g Release 1 (11.1.1), LDAP provider functionality is superseded by JpsUserProvider, in particular for cases such as nested group support.JpsUserProvider is installed and enabled with Content Server as a system component when Content Server is installed against an Oracle WebLogic Server instance. It also is available as a standard Content Server component. You can configure JpsUserProvider from the Providers page in Content Server. The connection also can be configured through the jps-config.xml file to use identity and credential stores.
If you want to authenticate against a JPS store, JpsUserProvider can be used to share the same security storage as another application with Oracle WebLogic Server. For example, you could use JpsUserProvider to share security storage with Image and Processing Manager software installed on an Oracle WebLogic server.
This section covers the following topics:
The Security Providers component can be used to add security by extending the functionality of basic incoming and outgoing socket providers with two new types of providers:
Secure Socket Layer (SSL) provider
Keepalive provider
Appropriate use of security providers, along with keys and certificates, can improve the security for network and Internet communication with Content Server. Benefits of using the Security Providers component include the following:
SSL enhances security for Web communication by providing communication encryption and authentication.
Security providers enable use of certificates for socket or server authentication.
Keepalive and connection pooling logic help avoid SSL expense overhead by reducing the amount of SSL socket creation and teardown.
The Security Providers component is installed (enabled) by default with Content Server.
To use the Security Providers component it is necessary to be familiar with socket providers, security and authentication, SSL, keepalive, and other aspects of security for network communication. The following sources of information can be useful in working with the Security Providers component:
Sun Java Secure Socket Extension (JSSE) Reference Guide for the Java 2 SDK, Standard Edition
This online document is available from Sun Microsystems at www.sun.com. It contains an extensive Related Documents section that includes Web links to reference books, security standards, government security policies and regulations, and a list of books on cryptography and SSL.
keytool Key and Certification Management Tool
This online document is available from Sun Microsystems at www.sun.com.
RSA's Public Key Cryptography Standards
This online document is available from RSA at www.rsasecurity.com.
RSA's Cryptography FAQ
This online document is available from RSA at www.rsasecurity.com.
SSL Certificate FAQ
This online document is available from The Linux Documentation Project at www.tldp.org.
The following table shows definitions for some of the security terms used in this section. For detailed information refer to the list of information references or to security and authentication standards sources.
| Term | Description |
|---|---|
| Certificate | A digital signature that verifies the identity and public key for an entity (a person or company). A certificate can be issued by a Certification Authority or by an individual entity. |
| Certificate Authority (CA) | An entity that issues certificates for other entities, and is recognized as a well-known and trusted source for certificates, such as VeriSign and Thawte. |
| Keystore | A file or database of information for keys, used for authentication processing. |
| Private key | Information packaged as a key that is known only to the entity that issues it. Private keys are used in generating signatures. |
| Public key | Information packaged as a key that is publicly associated with an entity. Public keys are used in verifying signatures. |
| SSL | Secure Socket Layer, a protocol for secure network communication using a combination of public and secret key technology. |
| Truststore | A file or database of keys that the trust manager has determined can be trusted. |
It is recommended that you determine how you want to use security providers before implementing SSL socket providers or keepalive socket providers. Examine the keepalive and SSL connection types and determine whether additional configuration is required to use the security providers you select, such as a need to create keystores or a truststore. Refer to the additional sources of information listed in "About Security Providers".
The following sections provide more information about the SSL and keepalive provider types, including the Java classes used to control the behavior of the provider types, and additional configuration that may be necessary.
The keepalive feature enables persistent connections and the pooling of socket connections for service requests. The setup for keepalive connections is most useful in situations where connection setup and teardown can take a considerable amount of time, and you want to minimize the time spent on that activity. The Security Providers component provides two keepalive socket providers: incoming and outgoing.
The following Java classes are used to set up the keepalive incoming socket provider:
| Java Class | Description |
|---|---|
| Provider Class | idc.provider.ExtendedSocketIncomingProvider |
| Connection Class | idc.provider.KeepaliveSocketIncomingConnection |
| Server Thread Class | idc.server.KeepaliveIdcServerThread |
The following Java classes are used to set up the keepalive outgoing socket provider:
| Java Class | Description |
|---|---|
| Provider Class | idc.provider.KeepaliveSocketOutgomingProvider |
| Connection Class | idc.provider.KeepaliveSocketOutgomingConnection |
| Request Class | idc.server.KeepaliveServerRequest |
The SSL provider setup enables the use of SSL connections in a keepalive environment. This setup is recommended over a simple SSL provider setup because it helps minimize the cost of SSL socket setup and teardown. The Security Providers component provides two SSL socket providers with keepalive: incoming and outgoing.
The following Java classes are used to set up the SSL keepalive incoming socket provider:
| Java Class | Description |
|---|---|
| Provider Class | idc.provider.ssl.SSLSocketIncomingProvider |
| Connection Class | idc.provider.KeepaliveSocketIncomingConnection |
| Server Thread Class | idc.server.KeepaliveIdcServerThread |
The following Java classes are used to set up the keepalive SSL outgoing socket provider:
| Java Class | Description |
|---|---|
| Provider Class | idc.provider.KeepaliveSocketOutgoingProvider |
| Connection Class | idc.provider.ssl.SSLSocketOutgoingConnection |
| Request Class | idc.provider.KeepaliveServerRequest |
Depending on which type of security provider you choose, there can be additional required configuration.
Keepalive and SSL outgoing providers—The Add Provider page includes a Num Connections field, which specifies the number of connections to pool.
SSL incoming providers—The Add Provider page includes two additional options:
Request Client Auth option—If clients are able, they should authenticate themselves when they make a connection.
Require Client Auth option—Clients must authenticate themselves in order to make a connection.
SSL providers may also require setup of a keystore or keystores, and a truststore, for both the client and server, depending on the value of the Request Client Auth option, the value of the Require Client Auth option, and what type of Certification Authority signed the certificates handled by these options. For information on keystores and truststore refer to "Keystores and Truststore".
SSL providers may require use of keystores and may require a truststore. Keystores are files that hold public and secret key information for use in SSL. A truststore contains certificates that have been determined to be trusted. If a certificate used on the server and client is signed by a well-known Certification Authority (CA) such as VeriSign or Thawte, then a truststore is not necessary, because the default JVM truststore contains the certificates of these CAs. Truststores are needed when certificates used by the SSL providers are self-signed or signed by a private CA. If SSL providers require keystores, and a truststore, then they must be created and managed.
The following sections provide overview information about keystores and truststore.
For detailed information on keystores and truststores refer to the sources of information listed in "About Security Providers".
When to Use Keystores and Truststore
The following examples present different situations and uses for keystores and a truststore.
The server requires a keystore containing a signed SSL certificate in order to create SSL sockets.
The server requests or requires client authentication, which may require a truststore. If the client's certificate is not signed by a well-known CA, then the server will need a truststore containing that CA's certificate.
The server requests or requires client authentication, which may require that the client have a keystore in which it stores the certificate the client presents for authentication.
The server uses a certificate that hasn't been signed by a well-known CA, therefore the client will require a truststore that contains the server's certificate.
Specifying Keystore and Truststore Information
In order to use keystore and truststore information, the SSL incoming and outgoing providers require that a file named sslconfig.hda be set up in the providers directory (next to the provider.hda file). The sslconfig.hda file contains configuration information you specify for your keystore and truststore. It has a format similar to the following example. For security reasons, there is no Web interface to assist in editing this file; all edits must be done manually using a text editor. Make certain no trailing spaces are included at the end of each line of this or any .hda file.
@Properties LocalDataTruststoreFile=/servers/idc/data/providers/ssloutgoing1/truststoreKeystoreFile=/servers/idc/data/providers/ssloutgoing1/keystore@end
| Configuration Name | Value Description |
|---|---|
| TruststoreFile | The full path to the truststore file. |
| KeystoreFile | The full path to the keystore file. |
This section describes the basic process for generating a keystore. You must determine the specific requirements and names for keys and keystores you want to create for your SSL providers. You can store keystore files wherever you want, because the sslconfig.hda file contains full paths for its KeystoreFile config settings. However, it is recommended that keystore files are stored in the IntradocDir/data/providers/provider_name directory (next to the provider.hda and sslconfig.hda files) or in the IntradocDir/config/ directory. Aliases and passwords are set using the provider page in Content Server.
For detailed information on how to use the keytool utility to generate a keystore, see the document titled keytool Key and Certification Management Tool, available online from Sun at www.sun.com.
Note:
The Java keytool utility has a feature that prevent direct interaction with private keys. This feature means that a certificate that is generated using keytool is "stuck" in the keystore; there is no way to retrieve the private key portion of the certificate. Inversely, there is no way for keytool to import a pre-existing certificate into a Java keystore.The Portecle Java keystore allows the import and export of private keys from Java keystores. For information refer to portecle.sourceforge.net.
To use keytool you must have the utility in your path when you enter the command.
Create a key in a keystore. The following command-line example shows how to create a key entry with the name alias in a keystore with the name keystore. This command prompts for a keystore password, for information that will be used to generate the key, and for a password for the key itself. If the password on the key is different from the password on the keystore, then the values KeystoreAlias and KeystoreAliasPassword are required to retrieve the key.
keytool -genkey -v -alias alias -keystore keystore
Generate a certificate signing request.The following command-line example shows how to generate a certificate signing request for the key entry named alias in the keystore named keystore, which is then stored in the file named csr_file. This file can be sent to a CA to be signed.
keytool -certreq -v -alias alias -keystore keystore -file csr_file
Import the CA's certificate into the keystore. The keytool checks the chain of trust on the user's certificate upon import. If the certificate was signed by a CA that is not well-known and the keytool knows nothing about the CA, the certificate is rejected. Therefore any certificate from a CA that is not well-known must first be imported into the keystore to permit the user's certificate to successfully be imported in the next step. The following command line example shows how to import a certificate in a file named cert_file into the keystore named keystore:
keytool -import -v -alias ca_alias -keystore keystore -file cert_file
Import the signed certificate back into the keystore. Once the certificate signing request has been received by a CA and the signed certificate is sent back from the CA, the certificate can be read into the keystore entry identified by alias.The following command line example shows how to import the signed certificate.
keytool -import -v -alias alias -keystore keystore_name -file csr_file
Check that everything is in the keystore.
keytool -list -v -keystore keystore_name
This section describes the basic process for generating a truststore. A truststore is necessary when an SSL provider uses keys that have not been signed by a well-known Certification Authority. A truststore contains only public certificates that have been verified by the person managing the truststore (the trust manager) for the Content Server. You must determine the specific requirements and name for the truststore you want to create. You can store a truststore file wherever you want, because the sslconfig.hda file contains a full path for a TruststoreFile config setting. However, it is recommended that a truststore file is stored in the IntradocDir/data/providers/provider_name directory (next to the provider.hda and sslconfig.hda files) or in the IntradocDir/config/ directory.
For detailed information on how to use the keytool utility to generate a truststore refer to the document titled keytool Key and Certification Management Tool, available online from Sun at www.sun.com.
To use keytool you must have the utility in your path when you enter the command.
The following command line example shows how to create a truststore:
keytool -import -v -alias alias -keystore keystore -file cert_files
| Variable | Description |
|---|---|
| alias | Alias name for the key. |
| keystore | Name of the keystore. |
| cert_file | Path to the Certification Authority's certificate. |
The following tasks are involved in managing providers.
To create an outgoing provider:
Display the Providers Page.
In the Create a New Provider table, click Add in the Action column for the outgoing provider type.
The Outgoing Provider Page is displayed.
Complete the following fields:
Required fields
Provider Name
Provider Description
Server Host Name
Server Port
Provider Class (predefined)
Optional fields
Connection Class (predefined)
Configuration Class
Relative Web Root
HTTP Server Address
Instance Name
Proxied (check box)
Notify Target (check box)
Users (check box)
Released Documents (check box)
Required Roles
Account Filter
Click Add.
The Providers page is displayed, with the new provider added to the Providers table.
Restart the content server.
It is recommend that you use Consulting Services to connect to other databases using a provider. Contact your sales representative for more information.
Consulting Services are required to use providers to connect to server sockets.
To add an incoming provider:
Display the Providers Page.
In the Create a New Provider section, click Add in the Action column for the incoming provider type.
The Incoming Provider Page is displayed.
Complete the following fields:
Required fields
Provider Name
Provider Description
Server Port
Provider Class (predefined)
Optional fields
Connection Class (predefined)
Configuration Class
Click Add.
The Providers page is displayed, with the new provider added to the Providers table.
Restart the content server.
See the Oracle Fusion Middleware Application Administrator's Guide for Content Server for instructions on adding the Preview provider. The HTML Preview feature zip file and guide are available for download from the Oracle Technology Network Web site.
To add a user provider which integrates with Oracle JPS (for Oracle WebLogic Server), follow these steps:
Display the Providers Page.
In the Create a New Provider table, click Add in the Action column for the ldapuser provider type.
The JPS User Provider Page is displayed.
Complete the following fields:
Required fields
Provider Name
Provider Description
Provider Class
Source Path
Optional fields
Connection Class
Configuration Class
JPS Context
Default Network Roles
To specify an attribute map:
Select an information field from the JPS Attributes list.
Select a Content Server user information field from the User Attribute list.
Click Add.
The attribute map is added to the text box.
If necessary, edit the attributes directly in the Attribute Map text box.
If necessary, change or add Default Network Roles.
Click Add.
The Providers page is displayed, with the new provider added to the Providers table.
Restart the content server.
Restart the Web server.
To add an incoming security provider, follow these steps:
Display the Providers Page.
In the Create a New provider table, click Add in the Action column for the keepaliveincoming or the sslincoming provider type. The keepaliveincoming Provider Page or the sslincoming Provider Page is displayed.
Complete the following fields:
Required Fields
Provider Name
Provider Description
Provider Class (predefined)
Server Port
Optional Fields
Connection Class (predefined)
Configuration Class
Server Thread Class (predefined)
Optional check boxes (sslincoming provider only)
Request Client Authentication
Require Client Authentication
Click Add. The Providers Page is displayed with the new provider added to the Providers table.
Restart the content server.
To add an outgoing security provider, follow these steps:
Display the Providers Page.
In the Create a New provider table, click Add in the Action column for the keepaliveoutgoing or ssloutgoing provider type. The keepaliveoutgoing Provider Page or the ssloutgoing Provider Page is displayed.
Complete the following fields:
Required Fields
Provider Name
Provider Description
Provider Class (predefined)
Server Host Name (predefined)
Server Port
Instance Name
Relative Web Root
Optional Fields
Connection Class (predefined)
Configuration Class
Request Class (predefined)
Number of Connections (predefined)
HTTP Server Address
Proxied (check box)
Notify Target (check box)
Users (check box)
Released Documents (check box)
Required Roles
Account Filter
Click Add. The Providers Page is displayed, with the new provider added to the Providers table.
Restart the content server.
To edit information for an existing provider (except for default system providers):
Display the Providers Page.
In the Providers table, click Info in the Action column for the provider to edit.
The Provider Information Page is displayed.
Click Edit.
The Add/Edit Provider Page is displayed.
Make the required changes.
Click Update to save the changes and return to the Providers page.
Restart the content server.
To delete an existing provider (except for default system providers):
Display the Providers Page.
In the Providers table, click the Info link in the Action column for the provider you want to delete.
The Provider Information Page is displayed.
Click Delete.
A confirmation screen is displayed.
Click OK.
The provider is removed from the Providers table.
Important:
Ensure that you intend to delete the provider and not just edit the information. When you delete a provider, the provider name and all of its related information is permanently removed from the Providers table.