Technical: Using REST web services with 2-legged OAuth on datapower.

2-legged OAuth consists of:

  • The client signs up to the server.
  • The server & client has a shared secret.  The client uses these key to gain access to resources on the server

What is REST ?

GET method

The client(secret=password) sends the following request to datapower.
Request: GET http://testname:1010/testname?name=KIM
Header: Authorization: OAuth     oauth_nonce=”12345abcde”,
oauth_consumer_key=”Kim”,
oauth_signature_method=”HMAC-SHA1″,
oauth_timestamp=”1319032126″,
oauth_version=”1.0″,
oauth_signature=”m2A6bZejY7smlH6OcWwaKLo7X4o=”

oauth_nonce = A randomly-generated string that is unique to each API call. This, along with the timestamp, is used to prevent replay attacks.
oauth_consumer_key = the client’s key.
oauth_signature_method = the cryptographic method used to sign.
oauth_timestamp = the number of seconds that have elapsed since midnight, January 1, 1970, also known as UNIX time.
oauth_signature = The authorization signature.

On datapower a Multi-protocol gateway needs to be configured allowing requests with an empty message body.

The secret needs to be shared between client and datapower. To make everything easy I stored the shared secret in an xml file in the “local:” file system of datapower.

The next step is verifying the signature. The best way to verify the signature is recreate the signature with the shared secret and then compare the two signatures. Of course to do this, some xslt skills are recommended.
This is the signature base-string that will be signed with the shared secret.

GET&http%3A%2F%2Ftestname%3A1010%2Ftestname&name%3DKIM%26oauth_consumer_key%3DKim

%26oauth_nonce%3D12345abcde%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1319032126%26oauth_version%3D1.0

How do we get to this?
If you look closely you see that there are 3 distinguished parts.

  1. GET&
  2. http%3A%2F%2Ftestname%3A1010%2Ftestname&
  3. name%3DKIM%26oauth_consumer_key%3DKim%26oauth_nonce%3D12345abcde%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1319032126%26oauth_version%3D1.0

The first part is fairly straightforward.
GET = the http method used.

The second part is the URL which is url-encoded.
We’ll need to percent encode all of the parameters when creating our signature. These “reserved” characters must be converted into their hexadecimal values and preceded by a % character. The rest of the characters are “unreserved” and must not be encoded.
The reserved characters are:
!   *   ‘   (   )   ;   :   @   &   =   +   $   ,   /   ?   %   #   [   ]  white-space
These are the percent-encoded values of the above characters:
%21 %2A %27 %28 %29 %3B %3A %40 %26 %3D %2B %24 %2C %2F %3F %25 %23 %5B %5D %20
Be careful with URL encoding functions built into languages, they may not encode all of the reserved characters, or may encode unreserved characters.
<xsl:variable
name=”BasicUrl”
select=”dp:encode(string(
dp:variable(‘http://testname:1010/testname’)
),’url’)
“/>

The third part gets a bit more complicated to do with xslt, because the number of parameters and OAuth header fields can change.
We need to extract the Oauth header from the request.
<xsl:variable
name=”OAuthParams”
select=”dp:request-header(‘Authorization’)”
/>
The URL parameters are also necessary. The parameters in this example are “name=KIM”. Put them all together and alphabetically organize them. You will get a string like this:
name=KIM&oauth_consumer_key=Kim&oauth_nonce=12345abcde&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1319032126&oauth_version=1.0
And again url-encode this string using the datapower function(dp:encode).If you now concatenate the 3 parts with a “&” you will get the signature base string.

The next thing we need to calculate the signature is the shared secret. OAuth standard uses a concatenation of the shared secret & token(<secret>&<token>). Since we are working with the 2-legged OAuth we don’t need the token and we can leave it empty. So in the example we used the shared secret “password”. Important is that you add the “&” behind the secret: ”password&”. Now we have the necessary information to calculate the signature.
<xsl:variable name=”Calculate_Signature”
select=”dp:hmac(‘http://www.w3.org/2000/09/xmldsig#hmac-sha1’,
‘password&’,
<SignatureBaseString>)”/>

Finally we can compare the signature of the OAuth header with our own calculated signature. Don’t forget to validate the timestamp against a predefined limit e.g. 5 minutes. If all checks out, the client is authorized to use the web service.

link to check OAuth signature

POST method is coming soon…

Author: Kim

blogger

blogger

Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

AWS AppFlow: Streamlining SaaS Integrations with AWS Services

In today’s digital world, organizations are constantly looking for ways to streamline their workflows and improve their data management processes. One of the key challenges that organizations face is integrating their various software as a service (SaaS) applications with their data management systems. This is

Read More »

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »