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:
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:
SOAP (Simple Object Access Protocol) is a lightweight XML-based messaging protocol used to encode the information in web service request and response messages before sending them over a network. SOAP requests are sent by the Oracle UCM web services to the Oracle WebLogic Server web services for implementation. For more information about SOAP, see Simple Object Access Protocol (SOAP) at http://www.w3.org/TR/soap12.
Web Services Security (WS-Security) is a standard set of SOAP extensions for securing web services for confidentiality, integrity, and authentication. For Oracle UCM web services, WS-Security is used for authentication, either for a client to connect to the server as a particular user or for one server to talk to another as a user. For more information, see the OASIS Web Service Security web page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.
Web Service Policy (WS-Policy) is a standard for attaching policies to web services. For Oracle UCM web services, policies are used for applying WS-Security to web services. The two supported policies are username-token security and Security Assertion Markup Language (SAML) security.
Historically, Oracle used Oracle Web Services Manager (OWSM) to secure its web services, and Oracle WebLogic Server used Web Services Security Policy (WS-SecurityPolicy) to secure its web services. Because web services security is partially standardized, some OWSM and WS-SecurityPolicy policies can work with each other.
Note:
Use OWSM policies over Oracle WebLogic Server web services whenever possible. You cannot mix your use of OWSM and Oracle WebLogic Server web services policies in the same web service.Oracle UCM web services (/idcws as context root) are SOAP based, while Oracle UCM native web services (/idcnativews as context root) are JAX_WS based. Both kinds of web services can be assigned OWSM policies through the Oracle WebLogic Server Administration Console.
The generic Oracle UCM web services are JAX-WS based and can be assigned OWSM policies and managed by OWSM. The native Oracle UCM web Services are SOAP based and can only support WS-Policy policies managed through the Oracle WebLogic Server Administration Console.
For more information about OWSM, see the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
A subset of WebLogic web service policies interoperate with OWSM policies. For more information, see "Interoperability with WebLogic Web Service Policies" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Web Services Security Policy (WS-SecurityPolicy) is a set of security policy assertions for use with the WS-Policy framework. For more information, see Web Services Security Policy (WS-SecurityPolicy) specification at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html.
SAML is an XML standard for exchanging authentication and authorization between different security domains. For more information, see the Security Assertion Markup Language (SAML) specification at http://docs.oasis-open.org/security/saml/v2.0/.
WebLogic Scripting Tool (WLST) is a command-line tool for managing Oracle WebLogic Server. For more information, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
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:
/idcws/ - Use this context root for general access to an Oracle Content Server instance through any regular web services client.
/idcnativews/ - The Remote IDC client (RIDC) uses the native web services. It is recommended that you do not develop custom client against these services.
The following table describes the Oracle UCM web service in the /idcws/ context root.
The following table describes the Oracle UCM web services in the idcnativews/ context root.
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.
The following subsections describe how to configure security for Oracle UCM web services.
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
Access the Oracle WebLogic Server Administration Console.
Select Deployments from the side panel, then expand either the Oracle UCM native web services or the Oracle UCM generic web services.
Select IdcWebLogicService or GenericSoapService, then click the Configuration tab, and then click the WS-Policy tab.
Click the main service. From here you can choose which OWSM policies to add.
When you have finished adding OWSM policies, you must update the Oracle UCM native web services or the Oracle UCM generic web services.
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.
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.
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>
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.
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>