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:

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:

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

In addition, you can create the following types of providers:

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.

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 Understanding Content Server Security Providers.

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:

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 Understanding Content Server Security Providers.

When to Use a Preview Provider

Preview providers are necessary to use HTML Preview and Content Categorizer.

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 11R1 (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.

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.

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

See Configuration Variables in Configuration Reference for Oracle WebCenter Content.

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

For example:

DoAccountCharMap=true
AccountCharMapSource=%
AccountCharMapTarget=/

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. See Configuration Variables in Configuration Reference for Oracle WebCenter Content. For more information on credentials mapping, see Credential Mapping.

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 When to Use a JpsUser Provider.

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:

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:

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:

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:

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.

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.

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

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

Additional Security Configuration

Depending on which type of security provider you choose, there can be additional required configuration.

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 Keystores and Truststore.

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 Understanding Content Server Security Providers.

When to Use Keystores and a Truststore

The following examples present different situations and uses for keystores and a truststore.

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.

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*

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.

Managing Providers

This section covers the following topics:

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, clickAdd 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.

    Note:

    Enterprise Search users must restart all open WebCenter Content Server instances when finished adding providers.

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 Configuring a System Database Provider for Standalone Mode, Configuring a JDBC Database Driver for Standalone Mode, and Configuring an External Database Provider for Standalone Mode.

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, clickAdd 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.

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, clickAdd 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.

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.

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.

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.

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 Retrieving Direct and Indirect Group Membership for Users.

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.

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 Providertable on the Providers page, clickAdd 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.

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.

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.