Tuesday, November 29, 2011

How to use drag-and-drop for creating a reusable processing rule in IBM Datapower

The basic method of creating a reusable processing rule is by dragging the cursor over a part of the existing processing rule. For a very small group of actions this is fine. If you want to make the rule a bit more advanced you probably want to create the processing rule from scratch. This can be achieved by creating a ‘Call processing rule’ action and create the reusable processing rule starting from there.

The problem with this approach is that you cannot use the Datapower drag-and-drop interface you use for all other processing rules. The GUI presents you the same view you get for all processing rules in the ‘Objects’ menu. It lists the different actions, but that’s it. No overview of the used contexts on mouse-over, or other details of the actions besides their name.

A simple solution to overcome this problem is to create the reusable rule in a Multi-Procotol Gateway Policy.
Go to the page ‘Multi-Protocol Gateway Policy’ by following the link in the menu on the left (Services>Multi-Protocol Gateway>Multi-Protocol Gateway Policy).
Create a new policy that will contain all future reusable rules. In my example I called it ‘ReusableRules’.
You can open this policy and add as much rules to it as you like. For the match action you can pick any existing match (f.e. all (url=*)). This match is only used in this policy. When calling a processing rule from within another rule the match action is not used.
 

To call this processing rule from within the ‘Call processing rule’ action you just have to select your newly created rule in the dropdown-box as you can see in the screenshot below.
 
Author: Tim

Thursday, November 24, 2011

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

Tuesday, November 15, 2011

Exposing a webservice in JBoss ESB

Webservice-based communication is of course at the core of SOA and as such the support should be easy and robust.
As the video demonstrates it is very easy to expose a service as a webservice and optionally demand validation.
Additionally it shows you how to enable WS-Security.

There are other ways to work with webservices:
- you can expose native jboss webservices
- create proxy webservices
- poll remote webservices



Link: http://www.youtube.com/watch?v=xflkWQZZsHE

Author: Alexander Verbruggen

Monday, November 14, 2011

OAuth

With the upcoming Devoxx conference, I did some reading last weekend. With Fri Nov 11 as a national holiday in Belgium - because of the end of World War I - I had some extra time. Looked a bit into most recent development around HTML 5 and Android development.

Quickly I ended up diving deeper into REST. Must confess that I was very WS-* minded and was not really impressed by REST initially. But with the incompleteness of WS-* and the success of REST, I'm changing my mind.

So I ended up browsing through the book "Restful Java with JAX-RS". This REST stuff triggered me into looking into different REST API's, including the one from Dropbox. And Dropbox security is based on OAuth, which triggered me to dive (back) into OAuth.

Looked for an OAuth book on Safari and Amazon, but none (yet?) avaialble. So I ended up re-reading chapter 9 of the the book "REST in practice". By the way, very good book, I like it. Some great links while looking around:
- The introduction on OAuth
- Good OAuth introduction by Yahoo
- Google Oauth Playground, so see OAuth live in action

While looking into OAuth, I started making the comparison with WS-Security and SAML in particular. With OAuth, no XML signing nor XML canonicalization, the option to use HMAC instead of keypairs and certificates. So simpler, but not simple!

Note: one of my I8C colleagues (Kim) just finished project on DataPower appliance to implement OAuth support

Author: Guy

Tuesday, November 8, 2011

jBPM Orchestration in JBoss ESB

The third installment in the JBoss ESB video series features the jBPM module which introduces service orchestration and human task flows.
The first video shows you how to set up a simple jBPM process:

Link: http://www.youtube.com/watch?v=jFBEqhAuOCw

The second one covers a few additional topics like variables passing back and forth between jBPM and the ESB services as well as user-driven branching:

Link: http://www.youtube.com/watch?v=9Mhd7VO0-oA

Author: Alexander Verbruggen

Wednesday, November 2, 2011

Custom java service in JBoss ESB


This second video in the JBoss ESB series demonstrates how to create a simple custom java service that prints out the message content it receives.

Link: http://www.youtube.com/watch?v=TfgUW0D-aAo

Author: Alexander Verbruggen