Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Universal Content Management
11g Release 1 (11.1.1)

Part Number E10807-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to current chapter
Up
Go to next page
Next
View PDF

12 Using Oracle UCM Web Services

This chapter describes how to use Oracle Universal Content Management (Oracle UCM) web services with Oracle WebLogic Server web services to manage Oracle Content Server.

This chapter includes the following sections:

12.1 Overview of Oracle UCM Web Services

Web services reside as a layer on top of existing software systems such as application servers, .NET servers, Oracle WebLogic Server, and Oracle Content Server. Web services can be used as a bridge to dissimilar operating systems or programming languages. Web services are adapted to the Internet as the model for communication and rely on the HyperText Transfer Protocol (HTTP) as the default network protocol. Thus, using web services, you can build applications using a combination of components.

Oracle UCM web services work with Oracle WebLogic Server web services to perform management functions for Oracle Content Server installed on Oracle WebLogic Server. Oracle WebLogic Server web services provide SOAP capabilities, and Oracle UCM web services include several built-in SOAP requests. Oracle UCM web services are automatically installed with an Oracle UCM instance, but they require additional configuration to set up security.

Core enabling technologies for Oracle UCM web services include:

12.2 Oracle UCM Web Services

Oracle UCM 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:

The following table describes the Oracle UCM web service in the /idcws/ context root.

Oracle UCM Web Service Descriptions
GenericSoapService This service uses a generic format similar to HDA for its SOAP format. It is almost identical to the generic SOAP calls that you can make to Oracle Content Server when you set IsSoap=1. Details of the format can be found in the published WSDL at idcws/GenericSoapPort?WSDL.

You can apply WS-Security to GenericSoapService through WS-Policy. Oracle Content Server supports Oracle Web Services Manager (OWSM) policies for Security Assertion Markup Language (SAML) and username-token.

As a result of allowing WS-Security policies to be applied to this service, streaming Message Transmission Optimization Mechanism (MTOM) is not available for use with this service. Very large files (greater than the memory of the client or the server) cannot be uploaded or downloaded.


The following table describes the Oracle UCM web services in the idcnativews/ context root.

Oracle UCM Web Services Descriptions
IdcWebRequestService This is the general Oracle UCM service. Essentially it is a normal socket request to Oracle Content Server, wrapped in a SOAP request. Requests are sent to Oracle Content Server using streaming Message Transmission Optimization Mechanism (MTOM) in order to support large files.

Streaming MTOM and WS-Security do not mix. As a result, do not apply WS-Security to this service, because it will break the streaming file support. In order to achieve security, you must first log in using the IdcWebLoginService, then use the same JSESSIONID received from that service in the next call to IdcWebRequestService as a cookie.

IdcWebLoginService This service is solely for adding security to IdcWebRequestService calls. There are no parameters for this service; it simply creates a session. The important field to retrieve is the JSESSIONID for future calls to IdcWebRequestService. If you want to use WS-Security with IdcWebRequestService, then apply it here. Oracle Content Server supports Oracle Web Services Manager (OWSM) policies for Security Assertion Markup Language (SAML) and username-token.

12.3 Installation and Configuration

The Oracle UCM web services are installed and ready to use by default with the Oracle UCM EAR. However, unless you configure WS-Security on any of the Oracle UCM web services, all connections to Oracle Content Server will use the “anonymous” user. Additional configuration is required to enable authentication.

12.4 Security

The following subsections describe how to configure security for Oracle UCM web services.

12.4.1 Configuring WS-Security through WS-Policy

Web service security (WS-Security) is set through the use of web service policies (WS-Policy). Security policies can be set to web services in order to define their security protocol. In particular, the Oracle UCM web services support OWSM policies.

Two general classes of policies are supported: username-token, and SAML. The following is a list of supported OWSM policies:

  • oracle/wss11_saml_token_with_message_protection_service_policy

  • oracle/wss11_username_token_with_message_protection_service_policy

To set WS-Policy

  1. Access the Oracle WebLogic Server Administration Console.

  2. Select Deployments from the side panel, then expand either the Oracle UCM native web services or the Oracle UCM generic web services.

  3. Select IdcWebLogicService or GenericSoapService, then click the Configuration tab, and then click the WS-Policy tab.

  4. Click the main service. From here you can choose which OWSM policies to add.

  5. When you have finished adding OWSM policies, you must update the Oracle UCM native web services or the Oracle UCM generic web services.

12.4.2 Configuring SAML Support

To provide SAML support so that the client can be the identity provider (that is, assert credentials) then additional steps must be taken to configure a keystore, configure a JPS provider to use the keystore, create a client credential store (CSF), and configure a Java client to use the keystore and CSF.

12.4.2.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 used in the following example are the defaults for the domain's config/fmwconfig/jps-config.xml file (explained in the next section):

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

Any relevant data can be entered in the keytool command, but the specifics do not matter except for the passwords for the keystore and the certificate, which the client uses.

12.4.2.2 Configuring Server JPS to Use the Keystore

Configuring the keystore on the Oracle WebLogic Server domain involves editing the $domain/config/fmwconfig/jps-config.xml file.A provider must be defined in <serviceProviders>. A provider should be defined by default.

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

When you have verified the provider, or created or modified a provider, a keystore instance must be defined in <serviceInstances>. A keystore instance should be defined by default.

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

The location of the keystore instance must be set to the same location as when you created the keystore. Additionally, the keystore must be added to <jpsContexts>. This setting should be in the jps-config.xml file by default.

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

12.4.2.3 Creating a Client CSF

On the client, there must be a credential store to store the keys to unlock the keystore. A Credential Store Framework (CSF) can be made in a variety of ways, but one way is to use the Oracle WebLogic Server Scripting Tool (WLST). You must use the wlst command from the EM interface. In order to use WLST to create a credential, you must be connected to the Oracle WebLogic Server domain. Note that the resulting wallet can be used only on the client.

$ ./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")

The preceding example creates a CSF wallet at $domain/config/fmwconfig/cwallet.sso that must be given to the client. You need to change the values from the example to match the alias and passwords from the keystore you created.

12.4.2.4 Configuring a Java Client to Use the Keystore and CSF

In order to configure a Java client to use the keystore and CSF, there are two requirements:

  • The Java client must have a copy of both the keystore and the CSF wallet.

  • There must be a client version of the jps-config.xml file. This file must contain entries for locating the keystore as well as the CSF wallet. To configure security, the Java system property “oracle.security.jps.config” must point towards the jps-config.xml file. This can be set during execution in the client.

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

The following example shows a jps-config.xml file for clients based on the configuration provided in previous examples.

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