This chapter provides an overview of managing Oracle WebCenter Portal's REST services in WebCenter Portal or Portal Framework applications.
This chapter includes the following sections:
Permissions:
To perform the tasks in this chapter, you must be granted the WebLogic ServerAdmin role through the Oracle WebLogic Server Administration Console and the Administrator role in the deployed application:
WebCenter Portal: Administrator role granted through Portal Builder Administration.
Portal Framework application: Administrator role granted through the Administration Console.
For more information about roles and permissions, see Section 1.8, "Understanding Administrative Operations, Roles, and Tools."
REST (REpresentational State Transfer) is an architectural style for making distributed resources available through a uniform interface that includes uniform resource identifiers (URIs), well-defined operations, hypermedia links, and a constrained set of media types. Typically, these operations include reading, writing, editing, and removing. Media types include JSON and XML/ATOM.
REST APIs are commonly used in client-side scripted, Rich Internet Applications. For example, a browser-based application written in Javascript can use Ajax techniques with REST APIs to send and receive application data from the server and update the client view.
Oracle WebCenter Portal provides a RESTful interface to many of its tools and services, like discussions, lists, people connections, and search. For a complete list of the services that support REST, see "Using Oracle WebCenter Portal REST APIs" in the Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
For a more complete introduction to REST and Oracle WebCenter Portal REST APIs, see "Using Oracle WebCenter REST APIs" in the Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
Oracle WebCenter Portal REST APIs are not enabled by default. To enable the REST APIs to work, you must perform the two separate server-side configurations: you must configure an identity asserter and you must seed required entries in the credential store to enable the REST security tokens to function properly. For more information on security tokens, see "Security Considerations for WebCenter Portal REST APIs" in the Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
Perform the following configuration tasks after Oracle WebCenter Portal is installed for the first time or if you know the configuration tasks have not been previously performed.
You must configure an identity asserter before using the REST APIs. For detailed instructions, see Section 31.9, "Configuring the REST Service Identity Asserter."
After configuring an identity asserter, the next step is to configure the WLS credential store. To configure the credential store, execute the following WLST commands while the server is running. No restart is required.
createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm",
user="keygen.algorithm", password="AES")
createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation",
user="cipher.transformation", password="AES/CBC/PKCS5Padding")
A user-scoped security token is embedded in the href and template attributes of every REST service URI. The token is both generated and validated by the server, and is enabled by the keygen.algorithm and cipher.transformation configuration steps described in Section 24.2.2, "Configuring the WebLogic Server Credential Store." The purpose of the security token is to prevent Cross-Site Request Forgery (CSRF) attacks.
For example:
<link template="opaque-template-uri/@me?startIndex={startIndex} &itemsPerPage={itemsPerPage}&utoken=generated-token" resourceType="urn:oracle:webcenter:messageBoard" href="opaque-uri/@me?token=generated-token" capabilities="urn:oracle:webcenter:read"/>
Note:
The security token is not used for authentication or identity propagation.Security tokens are based on the authenticated user's name. They do not expire, making it possible to both cache and bookmark the URIs.
Security tokens are also "salted," a cryptographic technique of adding extra characters to a string before encrypting it. Because of salting, if a security token is compromised, you will not have to change the user's user name across the entire system to address the problem.
This technique prevents cases where a user name is compromised and you don't want to have to change the user name system wide to fix the problem. If you need to regenerate the salt, you can do so by simply deleting it with the following WLST command:
deleteCred(map="o.webcenter.jf.csf.map", key="user.token.salt", user=" user.token.salt", password="AES")
For more information on security tokens, see "Security Considerations for WebCenter Portal REST APIs" in the Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
Although not required, in some cases you might want to change the root name for the REST APIs. The recommended technique for changing the REST root name is to do so by configuring a proxy server as described in Section 8.2.4, "Setting Up a Proxy Server." For example, through the proxy server configuration, the following two URIs refer to the same server:
http://myhost:8888/rest/api/resourceIndex
http://myhost:8888/pathname/rest/api/resourceIndex
This section explains techniques for enabling compression on the XML or JSON responses that are returned to the client by the Oracle WebCenter Portal REST APIs.
If you are running Apache, you can add the mod_deflate or mod_gzip server modules to the server configuration. Refer to the Apache documentation for more information.
If you are using Oracle HTTP Server (OHS), Oracle recommends using Oracle Web Cache for this purpose. For detailed information, see Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
If you are using OHS, you can also add the mod_deflate or mod_gzip server module to enable compression. For detailed information on this technique, see "Understanding Oracle HTTP Server Modules" in the Oracle Fusion Middleware Administrators Guide for Oracle HTTP Server.
For more information on Oracle Web Cache, see the section "Compression" in the Oracle Fusion Middleware Administrators Guide for Oracle HTTP Server, and see the chapter "Caching and Compressing Content" in the same guide.
By default, REST services are configured to accept authentication from identity assertion providers. If no identity assertion providers are configured, basic authentication is used.
For information on configuring identity assertion providers, see Section 31.9, "Configuring the REST Service Identity Asserter."
For more information, see "Configuring Authentication Providers" in Securing Oracle WebLogic Server.
Note:
Users can access the CMIS root anonymously. For more information, see "Security Considerations for CMIS REST APIs" in Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.