Consuming OAuth protected resources using Oracle Service Bus article series by Milco Numan

In this blog post, I will provide a general introduction of REST, explain some of the choices made and lay some of the ground work. The second part of this blog series will discuss the token management part while the third and final part describes the actual creation of the SOAP services providing the proxy to the external REST APIs.

With the introduction of SOA Suite 12c, the Oracle JCA REST adapter was introduced for use in both SOA and Service Bus 12c. This enables SOA developers to expose REST interfaces to their service consumers. A study by the Oracle A-team shows that in certain scenarios response times on mobile platforms may be reduced by an order of magnitude by consuming REST services instead of their SOAP equivalents.

However, using the REST adapter you cannot only expose REST interfaces to your own service implementations (inbound REST), but you can also consume REST services (outbound REST). In this series of blogs, I will demonstrate how I implemented a use case of “outbound” API management for a proof of concept, where the REST services were exposed as SOAP web services to our internal clients (which are largely “REST unaware”). An additional dimension is provided by the fact that the REST APIs invoked are secured by OAuth 2.0, so also some token management is needed in order to successfully invoke the service.

What about Security?

I am glad you asked. As SOAP has quite a number of standardized extensions in the realms of orchestration and security, this is very much “terra incognita” in the REST world. Well, not really. As REST is leveraging the HTTP protocol as the transport mechanism, a first step in security would be to use HTTPS (HTTP over SSL) to prevent an intermediary from eavesdropping on the communication between the service and the client. However, this will only prevent the interception of messages, it does not provide the server with any method of determining the origin of the request. Using HTTP Basic Authentication may be an option to force the client to sent some identification to the server, but the problem is that this scenario is not very useful for application to application message exchange as it does not provide options to provide temporary access or to revoke the access.

Enter OAuth, “an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.” Version 2.0 of this protocol has been published in 2012 and is widely in use for securing access and authorization to services, e.g. Google, LinkedIn, Facebook, Dropbox and Paypal to name a few.

What is REST?

What is REST? And how does if differ from SOAP? Well, first of all REST and SOAP are intended to access (remote) Web Services. Where SOAP is a heavy-weight protocol, involving predefined message structures and formats, REST is defined very loosely as an “architectural style”. Messages transmitted to SOAP web services are always encoded as XML data structures, whereas the payload in REST can be either XML or JSON. The latter seems to be the preferred format nowadays, I came across a site describing JSON as “The Fat-Free Alternative To XML“.

In REST, you are manipulating “resources” (types of objects, e.g. customers, orders, items and the like) using standard HTTP methods. You’d use the GET method on a resource to retrieve a single instance or collection, use the HTTP POST method to create a new one, update a resource instance using HTTP PUT and the HTTP DELETE takes care of removing an object. Read part 1 here and read part 2 here and read part 3 here

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki