13 Configuring Providers

This chapter describes Oracle WebCenter Content supported providers and explains when and how to use provider connections between WebCenter Content Server and Oracle WebLogic Server or other providers such as Lightweight Directory Access Protocol (LDAP).

This chapter includes the following topics:

13.1 About Content Server Providers

A provider is an Application Programming Interface (API) that establishes a connection between the Content Server instance and outside entities. These entities include:

  • Oracle WebLogic Server

  • LDAP servers

  • databases

  • server sockets

  • file store system

  • Inbound Refinery

By default, the Content Server instance has three system providers:

  • SystemDatabase: The system database.

  • SystemServerSocket: A server socket that listens for browser requests.

  • DefaultFileStore: A file store system.

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. For information on using SSL with an outgoing provider, see Section 13.3.

  • 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. For information on using SSL with an incoming provider, see Section 13.3.

  • 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.

  • Preview: An outgoing provider connectionfor use with the optional HTML Preview feature.

  • JpsUser: 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 instance. This type of provider is supported by the JpsUserProvider component, which is installed (enabled) by default with the Content Server instance.

  • Ldapuser: A connection initiated to a Lightweight Directory Access Protocol (LDAP) server for managing external user access to the Content Server instance. This type of provider is supported by the ActiveDirectoryLdap component, which is installed (disabled) by default during installation.

    Note:

    As of 11g Release 1 (11.1.1) Ldapuser functionality is superseded by JpsUser, in particular for nested group support.

  • HTTP: A connection that allows communication between Content Server instances using the HTTP protocol. This type of provider is supported by the ProxyConnections component, which is installed (enabled) by default during Content Server installation. For information on when and how to use this type of connection, see Chapter 21.

13.2 Choosing an Appropriate Provider

The different types of providers described in the previous section are used 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 used in each scenario.

13.2.1 When to Use an Outgoing Provider

Outgoing providers are necessary to use the Content Server Archiver utility and Oracle WebCenter Content: Inbound Refinery. If you want to use SSL or keepalive with an outgoing provider, see details in Section 13.3.

  • Archiver Utility (Content Server): The Archiver is a utility within the core Content Server 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 more information about the Transfer feature, the different types of transfers and the outgoing provider requirements, see Chapter 23.

  • 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 Managing Oracle WebCenter Content.

13.2.2 When to Use a Database Provider

Database providers are necessary 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 Content Server, search results can be combined and viewed on a single search page. Additionally, data can be imported from these external database sources.

Administrators can create a database provider with 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 on creating a JDBC data source for a WebLogic domain server, see Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).

  • 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.

13.2.3 When to Use an Incoming Provider

Incoming providers are necessary 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 Section 13.3.

  • Archiver Utility (Content Server): The Archiver is a utility within Content Server 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.

  • Oracle WebDAV Support: With Content Server version 7.0 and later, Web-Based Distributed Authoring and Versioning (WebDAV) support is provided by a custom feature, so an incoming provider and servlet engine are not necessary.

    For more information about WebDAV, see Oracle Fusion Middleware Managing Oracle WebCenter Content.

13.2.4 When to Use a Preview Provider

Preview providers are necessary 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 website. 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 Oracle Fusion Middleware Managing Oracle WebCenter Content.

  • Content Categorizer: Content Categorizer suggests metadata values for documents being checked in to 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.

    For more information about Content Categorizer, see Oracle Fusion Middleware Managing Oracle WebCenter Content. This guide provides relevant information about any additional products that may be required or are optional.

13.2.5 When to Use a JpsUser Provider

JpsUser is the default provider for the WebCenter Content Server instance to communicate user information and credentials managed through the Oracle WebLogic Server Administration Console. For Oracle WebCenter Content and Content Server instances, it is recommended that you use the JpsUser provider.

Note:

As of Release 11gR1, direct LDAP provider functionality is superseded by the JpsUser provider for a Content Server instance, in particular for cases such as nested group support.

Note:

If a site is upgrading from an 10g or earlier release of WebCenter Content software and is using Active Directory, LDAP, or Active Directory with LDAP, information about those providers is available in the Release 10gR3 document Managing Security and User Access. It is strongly recommended that sites upgrade to use JpsUser provider.

The system-defined JpsUser provider connects to the Content 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 WebCenter 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.

The JpsUserProvider component is installed and enabled as a system component when the Content Server instance is installed against an Oracle WebLogic Server instance. JpsUserProvider also is available as a standard Content Server component.

Caution:

It is unlikely that a site would ever add another JpsUser provider in addition to the system-defined JpsUser provider. Adding another such provider could cause problems for the WebCenter Content Server installation.

You can edit the JpsUser provider configuration using the Providers page in the Content Server instance. The connection configuration also can be edited through the jps-config.xml file to use identity and credential stores.

If you want to authenticate against a JPS store, JpsUser provider can be used to share the same security storage as another application on an Oracle WebLogic Server instance. For example, you could use JpsUser provider to share security storage with Image and Processing Manager software installed on an Oracle WebLogic Server instance.

Note:

As of release 11gR1 (11.1.1.6.0) Oracle WebCenter Content supports use of the Oracle Virtual Directory library (LibOVD) feature, which enables a site to use multiple providers for login and group membership information through JpsUserProvider. For example, it would be possible to use both Oracle Internet Directory (OID) and Active Directory as sources of user and role information. For information on multi-LDAP configuration in Oracle WebLogic Server, see Oracle Fusion Middleware Application Security Guide.

13.2.5.1 Retrieving Direct and Indirect Group Membership for Users

JpsUser provider includes the UseNestedGroups configuration option to specify whether Content Server retrieves users' direct and indirect group membership in the authentication provider, or just users' direct group membership.

If UseNestedGroups is set to FALSE, only users' direct group membership is retrieved from the authentication provider.

If UseNestedGroups is set to TRUE, both direct and indirect group membership is retrieved from the authentication provider. This is the default behavior for the JpsUser provider.

The configuration setting is located in the file IntradocDir/data/providers/jpsuserprovider/provider.hda.

13.2.5.2 Custom Field Mapping from LDAP Server

If you map custom fields from your LDAP service to WebCenter Content through the JpsUser provider, the default behavior is to take no action if the custom field is empty. For example, if you had a custom field with the value 123456789 and then removed the value, Oracle WebCenter Content will ignore the missing attribute and continue to reflect 123456789 on the basis that custom fields are unlikely to be empty.

To clear a custom field in WebCenter Content, you must change the default behavior by enabling and setting the variable ClearMissingAttributes=true in the provider.hda file for JpsUser. The default location for this file is Domain_Home/ucm/cs/data/providers/jpsuserprovider/provider.hda. Add the variable before the @end line in the file. For example:

SourcePath=jpsuser
ProviderClass=idc.provider.jps.JpsUserProvider
ClearMissingAttributes=true
@end

For details on this variable, see Oracle Fusion Middleware Configuration Reference for Oracle WebCenter Content.

13.2.5.3 Single Character Mapping for Accounts

WebCenter Content supports the use of single character mapping to specify an account hierarchy retrieved from a flat LDAP structure, such as a % (percent sign) character as a separator to be mapped to a / (forward slash) character. The mapping takes place after all other filtering and name collapsing is performed.

Three settings control this behavior. They can be specified in the Domain_Home/ucm/cs/data/providers/jpsuserprovider/provider.hda file or in the DomainHome/ucm/cs/config/config.cfg file

  • DoAccountCharMap: (Boolean) Enables or disables the option. Can be set to 1 or true. The default is false.

  • AccountCharMapSource: Specifies the single character in the user store group (account). The default is %.

  • AccountCharMapTarget: Specifies the single character in the Oracle WebCenter Content account name. The default is /.

For example:

DoAccountCharMap=true
AccountCharMapSource=%
AccountCharMapTarget=/

13.2.5.4 Credential Map for JpsUser Provider

You can define a Credential Map for the JpsUser provider by enabling and setting the variable ProviderCredentialsMap=name_of_map in the file Domain_Home/ucm/cs/data/providers/jpsuserprovider/provider.hda. For details on this variable, see Oracle Fusion Middleware Configuration Reference for Oracle WebCenter Content. For more information on credentials mapping, see Section 21.2.

13.2.6 When to Use a Ldapuser Provider

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 an application 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.

Note:

As of Release 11gR1, Ldapuser provider functionality is superseded by JpsUserProvider for Content Server. Use of the Content Server LDAP provider is not recommended for user and security management for Content Server. For more information, see Section 13.2.5.

If you decide to use a LDAP server (other than Active Directory, which can be integrated directly with the Content Server instance), you must create a Ldapuser provider to set up communication between the Content Server instance and the LDAP server. When properly configured, the Ldapuser provider authorizes external users through the mapping properties that are linked to role assignments and account permissions (defined on the LDAP Provider page).

For information on LDAP servers that Oracle Fusion Middleware supports, see the certification information on the Oracle Technology Network:

http://www.oracle.com/technetwork/middleware/webcenter/content/documentation/documentation-155348.html

Although not required, you are encouraged to have Consulting Services assist you with creating a LDAP security model and deploying the LDAP integration. Contact your sales representative for more information.

LDAP integration can be useful with the following content management products and architectures:

  • 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 instance 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, a LDAP provider must be created.

    For more information about the related data repositories, report generation, producing queries and installation procedures, see Oracle Fusion Middleware Managing Oracle WebCenter Content.

13.3 Understanding Content Server Security Providers

Aside from security configuration integration between Content Server and other Oracle applications, the Content Server's own SecurityProviders component can be used to add security by extending the functionality of basic incoming and outgoing socket providers with two 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 the Content Server instance. Benefits of using the SecurityProviders 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 SecurityProviders component is installed (enabled) by default with the Content Server instance.

References

To use the SecurityProviders 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 SecurityProviders component:

  • Java Secure Socket Extension (JSSE) Reference Guide for the Java 2 SDK, Standard Edition

    This online document is available from Oracle. 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 Oracle.

  • RSA's Public Key Cryptography Standards

    This online document is available from RSA at

    http://www.rsasecurity.com

  • RSA's Cryptography FAQ

    This online document is available from RSA at

    http://www.rsasecurity.com

  • SSL Certificate FAQ

    This online document is available from The Linux Documentation Project at

    http://www.tldp.org

Terminology

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 organization). 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.


13.3.1 Planning to Use Security Providers

It is recommended that you determine how you want to use security providers before implementing SSL socket providers or keepalive socket providers for Content Server. 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.

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.

13.3.1.1 Keepalive Connections

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 SecurityProviders 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


13.3.1.2 SSL Connections

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 SecurityProviders 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


13.3.1.3 Additional Security Configuration

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, see Section 13.3.2.

13.3.2 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 more information on keystores and truststores see the sources of information listed in Section 13.3.

13.3.2.1 When to Use Keystores and a 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.

13.3.2.2 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.


13.3.2.3 Generating a Keystore

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 the Content Server instance.

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 Oracle.

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.

  1. 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
    
  2. 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
    
  3. 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
    
  4. 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
    
  5. Check that everything is in the keystore.

    keytool -list -v -keystore keystore_name
    

13.3.2.4 Creating a Truststore

This section describes the basic process for generating a truststore. A truststore is necessary when a 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 instance. 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 at http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html. To use the keytool utility 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.


13.4 Managing Providers

This section covers the following topics:

13.4.1 Adding an Outgoing Provider

To add an outgoing provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New Provider table on the Providers page, click Add in the Action column for the outgoing provider type.

  3. Enter configuration values on the Outgoing Socket Provider page:

    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

    • Required Roles

    • Account Filter

    Optional Check Boxes

    • Proxied

    • Notify Target

    • Users

    • Released Documents

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.2 Adding a Database Provider

Database provider configuration is specified when WebCenter Content and the Content Server instance are installed in an Oracle WebLogic Server domain.

Note:

If you want to configure database connections for standalone mode, see Section 3.5.2.3, Section 3.5.2.4, and Section 3.5.2.5.

To add a database provider:

  1. Using a web browser, access your Content Server home page and select Administration, then Providers.

  2. In the Create a New Provider section of the Providers page, click Add in the Action column for the database provider type.

  3. Enter configuration values on the Database Provider page:

    Required Fields

    • Provider Name

    • Provider Description

    • Provider Class (predefined)

    • Database Type

    • JDBC Driver

    • JDBC Connection String

    • Test Query

    Optional Fields

    • Connection Class (predefined)

    • Configuration Class

    • Data Source

    • Database Directory

    • Database Name

    • JDBC User

    • JDBC Password

    • Number of Connections (default provided)

    • Extra Storage Keys (default provided)

    • Additional Settings

    Optional Check Boxes

    • Use Data Source

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.3 Adding an Incoming Provider

Consulting Services are required to use providers to connect to server sockets.

To add an incoming provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New Provider section on the Providers page, click Add in the Action column for the incoming provider type.

  3. Enter configuration values on the Incoming Provider page:

    Required Fields

    • Provider Name

    • Provider Description

    • Server Port

    • Provider Class (predefined)

    Optional Fields

    • Connection Class (predefined)

    • Configuration Class

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.4 Adding a Preview Provider

For instructions on adding the Preview provider, see the information provided with the HTML Preview feature zip file. The HTML Preview feature zip file and guide are available for download from the Oracle Technology Network website.

13.4.5 Adding an Incoming Security Provider

To add an incoming security provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New provider table on the Providers page, click Add in the Action column for the keepaliveincoming or the sslincoming provider type.

  3. Enter configuration values on the keepaliveincoming Provider page or the sslincoming Provider page:

    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

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.6 Adding an Outgoing Security Provider

To add an outgoing security provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New provider table on the Providers page, click Add in the Action column for the keepaliveoutgoing or ssloutgoing provider type.

  3. Enter configuration values on the keepaliveoutgoing Provider page or the ssloutgoing Provider page:

    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

    • Required Roles

    • Account Filter

    Optional Check Boxes

    • Proxied

    • Notify Target

    • Users

    • Released Documents

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.7 Adding a JpsUser Provider

A default JpsUser provider, which integrates with Oracle JPS (for an Oracle WebLogic Server instance), is provided with installation of the WebCenter Content system.

Caution:

It is unlikely that a site would ever add another JpsUser provider in addition to the system-defined JpsUser provider. Adding another such provider could cause problems for the Content Server installation.

For information on configuration options in addition to those specified on the JpsUser Provider page, see Section 13.2.5.1.

To add a JpsUser provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New Provider table on the Providers page, click Add in the Action column for the jpsuser provider type.

  3. Enter configuration values on the JPS User Provider page:

    Required fields

    • Provider Name

    • Provider Description

    • Provider Class (predefined)

    • Source Path

    Optional fields

    • Connection Class

    • Configuration Class

    • JPS Context

    • Default Network Roles

  4. To specify an attribute map:

    1. Select an information field from the JPS Attributes list.

    2. Select a Content Server user information field from the User Attribute list.

    3. Click Add. The attribute map is added to the text box.

    4. If necessary, edit the attributes directly in the Attribute Map text box.

  5. If necessary, change or add Default Network Roles.

  6. Click Add. The Providers page opens with the new provider added to the Providers table.

  7. Restart the Content Server instance.

  8. Restart the web server.

13.4.8 Adding a HTTP Outgoing Provider

To add a HTTP outgoing provider:

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Create a New Provider table on the Providers page, click Add in the Action column for the httpoutgoing provider type.

  3. Enter configuration values on the Outgoing Http Provider page:

    Required fields

    • Provider Name

    • Provider Description

    • Provider Class (predefined)

    • CGI URL

    • Instance Name

    • Relative Web Root

    Optional fields

    • Connection Class (predefined)

    • Configuration Class

    • Connection Password Name

    • Connection Password

    • Client IP Filter

  4. Click Add. The Providers page opens with the new provider added to the Providers table.

  5. Restart the Content Server instance.

13.4.9 Editing Provider Configuration

To edit the configuration for an existing provider (except for default system providers):

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Providers table on the Providers page, click Info in the Action column for the provider to edit.

  3. In the Provider Information page, click Edit.

  4. In the Add/Edit Provider page, make the required changes.

  5. Click Update to save the changes and return to the Providers page.

  6. Restart the Content Server instance.

13.4.10 Deleting a Provider

To delete an existing provider (except for default system providers):

  1. Using a web browser, access your Content Server home page and choose Administration, then Providers.

  2. In the Providers table on the Providers page, click the Info link in the Action column for the provider you want to delete.

  3. In the Provider Information page, click Delete.

  4. Click OK on the confirmation window. 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.