19 Configuring WebCenter Content Web Services for Integration

19.1.1 WebCenter Content Web Services

WebCenter Content provides two types of web services: a general (generic) JAX-WS based web service, and a native SOAP based web service. The two types of web services reside in two different context roots. The context root is the primary identifier in the URL for accessing the web services.

The context roots follow:

• idcws

  Use this context root for general access to Content Server through any regular web services client.

• idcnativews

  The Remote Intradoc Client (RIDC) uses the native web services. Oracle recommends that you do not develop a custom client against these services. For more information about RIDC, see Chapter 23, "Using RIDC to Access Content Server."

The following table describes the WebCenter Content web service in the idcws context root.

The following table describes the WebCenter Content web services in the idcnativews context root.

19.2.1 Configuring WS-Security through WS-Policy

WS-Security is set through the use of web service policies (WS-Policy). Security policies can be set for web services to define their security protocol. In particular, the WebCenter Content web services support Oracle WSM policies.

WebCenter Content supports two general classes of policies, username-token and SAML, and the following Oracle WSM policies:

• oracle/wss11_saml_token_with_message_protection_service_policy

• oracle/wss11_username_token_with_message_protection_service_policy

To configure WS-Security through WS-Policy:

1. Access the Oracle WebLogic Server Administration Console.

2. Select Deployments from the side panel.

3. Expand either WebCenter Content Native Web Services or WebCenter Content Web Services in the Deployments table.

4. Click the name of a web service, such as GenericSoapService

5. Click the Configuration tab on the Settings page for the web service, and then click the WS-Policy tab.

6. Click the main service. From here you can choose which Oracle WSM policies to add.

7. When you have finished adding Oracle WSM policies, you need to update the WebCenter Content native web services or the WebCenter Content generic web services to save your additions.

19.3.1 Configuring a Keystore

Both the server and client need a copy of a keystore. The server uses the keystore to authenticate the credentials passed by the client. A self-signed certificate can work for this situation, because the keystore is used only as a shared secret. You can use the keytool utility to generate a self-signed certificate. Many of the values in the following example are the default values for the domain's config/fmwconfig/jps-config.xml file, described in Section 19.3.2, "Configuring JPS for WebCenter Content to Use the Keystore":

$ keytool -genkey -alias orakey -keyalg RSA -keystore default-keystore.jks -keypass welcome -storepass welcome

You can enter any relevant data in the keytool command. The specifics do not matter except for the passwords for the keystore and the certificate, which the client uses.

19.3.2 Configuring JPS for WebCenter Content to Use the Keystore

Configuring the keystore in an Oracle WebLogic Server domain involves editing the DomainHome/config/fmwconfig/jps-config.xml file.

To configure JPS for WebCenter Content to use the keystore:

1. Verify that a provider is defined in the <serviceProviders> element, or define one.

   A provider should be defined in this element by default. If not, you need to add a <serviceProvider> element that defines a provider, as Example 19-1 shows.

   Example 19-1 Service Provider Definition in jps-config.xml

   <serviceProviders>
     <serviceProvider type="KEY_STORE" name="keystore.provider"
         class="oracle.security.jps.internal.keystore.KeyStoreProvider">
         <description>PKI Based Keystore Provider</description>
         <property name="provider.property.name" value="owsm"/>
     </serviceProvider>
   </serviceProviders>
   

2. Verify that a keystore instance is defined in <serviceInstances>.

   A keystore instance should be defined by default.

   A keystore instance should be defined in this element by default. If not, you need to add a <serviceInstance> element that defines a keystore instance, as Example 19-2 shows.

   Example 19-2 Keystore Instance Definition in jps-config.xml

   <serviceInstances>
     <serviceInstance name="keystore" provider="keystore.provider"
         location="./default-keystore.jks">      <description>Default JPS Keystore Service</description>      <property name="keystore.type" value="JKS"/>      <property name="keystore.csf.map" value="oracle.wsm.security"/>      <property name="keystore.pass.csf.key" value="keystore-csf-key"/>      <property name="keystore.sig.csf.key" value="sign-csf-key"/>      <property name="keystore.enc.csf.key" value="enc-csf-key"/>  </serviceInstance>
   </serviceInstances>
   

   The location of the keystore instance must be set to the same location as where you created the keystore.

3. Verify that a reference to the keystore is in the <jpsContexts> element.

   This setting should be in the jps-config.xml file by default. If not, you need to add the setting, as Example 19-3 shows.

   Example 19-3 Keystore in the JPS Context

   <jpsContext name="default">    <serviceInstanceRef ref="credstore"/>    <serviceInstanceRef ref="keystore"/>    <serviceInstanceRef ref="policystore.xml"/>    <serviceInstanceRef ref="audit"/>    <serviceInstanceRef ref="idstore.ldap"/></jpsContext>
   

4. Save the jps-config.xml file, and restart the WebCenter Content Managed Server and the Administration Server, as described in Section 15.4, "Restarting Content Server to Apply a Component."

19.3.3 Creating a Client CSF

On the client, there must be a credential store to store the keys to unlock the keystore. Oracle WebLogic Server provides a variety of ways to create a Credential Store Framework (CSF). One way you can create a CSF is with Oracle WebLogic Server Scripting Tool (WLST) commands.

To create a client CSF

1. Connect to the Oracle WebLogic Server domain, as Example 19-4 shows.

   Example 19-4 Creating a Client CSF with WLST Commands

   $ ./wlst.sh
   
   $ connect()
   
   $ createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore", password="welcome")
   $ createCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password="welcome")
   $ createCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password="welcome")
   

2. Use WLST createCred commands to define the CSF, as Example 19-4 shows.

   Change the values in the example to match the alias and passwords from the keystore you created.

   WLST creates a CSF wallet at DomainHome/config/fmwconfig/cwallet.sso. You can use the wallet only on the client.

3. Exit from WLST, and restart the Administration Server for the domain.

4. Send a copy of the wallet to the client.

19.3.4 Configuring a Java Client to Use the Keystore and CSF

Before you can configure a Java client to use the keystore and CSF, the client must have these items:

• A copy of the keystore

• A copy of the CSF wallet

• A client version of the jps-config.xml file

To configure a Java client to use the keystore and CSF:

1. Edit the jps-config.xml file for the Java client.

2. Add the locations of the keystore and the CSF wallet, as Example 19-5 shows, and save the file.

   Example 19-5 Keystore and CSF Locations in the jps-config.xml file for a Java Client

   <jpsConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="jps-config.xsd">    <serviceProviders>        <serviceProvider name="credstoressp" 
                    class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">            <description>SecretStore-based CSF Provider</description>        </serviceProvider>               <serviceProvider type="KEY_STORE" name="keystore.provider" 
                    class="oracle.security.jps.internal.keystore.KeyStoreProvider">            <description>PKI Based Keystore Provider</description>            <property name="provider.property.name" value="owsm"/>        </serviceProvider>    </serviceProviders>    <serviceInstances>        <serviceInstance name="credstore" provider="credstoressp" location="./"> 
               <description>File Based Credential Store Service Instance</description> 
           </serviceInstance>               <serviceInstance name="keystore" provider="keystore.provider" 
                    location="./default-keystore.jks"> 
               <description>Default JPS Keystore Service</description> 
               <property name="keystore.type" value="JKS"/> 
               <property name="keystore.csf.map" value="oracle.wsm.security"/> 
               <property name="keystore.pass.csf.key" value="keystore-csf-key"/>
               <property name="keystore.sig.csf.key" value="sign-csf-key"/> 
               <property name="keystore.enc.csf.key" value="enc-csf-key"/> 
           </serviceInstance> 
       </serviceInstances>    <jpsContexts default="default">        <jpsContext name="default">            <serviceInstanceRef ref="credstore"/>            <serviceInstanceRef ref="keystore"/>        </jpsContext>    </jpsContexts></jpsConfig>
   

3. Set oracle.security.jps.config, a Java system property, to point to the jps-config.xml file:

   System.setProperty("oracle.security.jps.config", “jps-config.xml”);
   

   You can set this location in the client, during execution.