OAuth Implementation in Datapower XI52

OAuth is an authorization framework that allows a resource owner to grant permission to access their resources without sharing their credentials with a third party. Traditionally in client-server authentication model, the client uses its credentials to access its resources hosted by the server. OAuth introduces a third role called the resource owner. In this model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner, but hosted by the server.

Below figure shows OAuth in Datapower,

How to Use It?

To use the OAuth protocol, we need an AAA policy. The AAA policy must be defined in a processing rule of Web Token Service or Multi-Protocol Gateway.After successfully generating an access token, processing returns a node set that becomes part of the JSON object that contains the access token and optionally a refresh token.

1.     When configured through a Web Token Service, the service supports as authorization server endpoints

2.     When configured through a Multi-Protocol Gateway, the service supports as authorization server endpoints and enforcement point for resource servers.

Types of Protocol Flow

1.     Three Legged Flow – There are 3 entities namely the resource owner, an OAuth client who wants to access the resource, the resource server. The resource owner does not share its credentials to client instead it gives authorization grant and a client ID by an authorization service. Using authorization grant, OAuth client request an access token from authorization service to access the resource on resource server.

2.     Two Legged Flow – There are only 2 entities where the resource owner and OAuth client overlaps. The client needs resource owner credentials or a client credentials grant type. There are four credential grant type scenarios.

1. Implementation (Two legged Flow) through WTS (Grant type scenario- resource owner password credentials)

This scenario involves exchanging the resource owner’s username and password for an access token and make use of that token to access resources, which means the client possess the resource owner’s credentials. Client application sends a token request containing the resource owner username and password as well as its information to an authorization server and receives an access token. When acting as an authorization server, Datapower accepts and verifies an OAuth request and generates an access token. When acting as an enforcement point for a resource server, Datapower verifies the access token and validates it against the resource the client is requesting. Below steps describes this implementation,

STEP 1 Create an OAuth client object as below,

STEP 2 Create an OAuth client group object as below,

STEP 3 Create a AAA Policy with OAuth Config,

3 A. Extract Identity (EI)

3 B. Authentication (AU)

3 C. Resource Extraction(ER)

3 D. Authorization (AZ)

Sample AAA file,

STEP 4 Create an authorization server using the Web Token Service as below,

4 A.WTS Config,

4 B.WTS generated Processing Policy,

STEP 5 Create a resource server enforcement point using the Multi-Protocol Gateway as below,

5 A. Front Side Handler Config,

5 B. Processing policy for enforcement,

5 C. choose a static backend type, here it is a simple loopback XML Firewall. Request type as non-xml, Response type as Pass through and propagate URI to on.

STEP 6 Testing the Configuration,

6 A. Client request to invoke the authorization service and fetch access token (Web token service)

Curl command,

curl -k https://<dp:ip>:5040/ –user password-client:passw0rd -d “grant_type=password&username=john&password=passW&scope=/getAccount {“token_type”:”bearer”,”access_token”:”bearer”,”expires_in”:3600 }”

6 B. Access token verified by the MPGW (Resource Service)

Curl command,

curl -k https://<dp:ip>:5041/getAccount -H “Authorization: Bearer AAEPcGFzc3dvcmQtY2xpZW50tOItBbbumS0yrr/H+fPT8VbAvrI3xX55MSfy7Pnjz07usWpDnPm+0evCFTcPjtUwt5SrAhdplb3QnH+Dy36pCg”

2.Implementation (Two legged Flow) through WTS (Grant Type Scenario-Client Credential)

In this scenario client itself the resource owner, which means client can get an access token by presenting its own credentials, avoiding its credentials from being exposed in each and every resource request.However,client credentials flow implementation is similar to resource owner password credentials configuration,

STEP 1 Configure the OAuth client application with the Datapower,

1 A.Configure an OAuth Client Profile similar to above implementation except for the grant type as below,

1 B. Configure the created client profile with OAuth Client Group,

1 C. Use the OAuth client group in AAA policy to implement in Authorization service,

Authentication(AU)

Resource Extraction(ER)

Authorization (AZ)

1 D. Use the OAuth client group in another AAA policy(below Config) to implement in Enforcement service,

Resource Extraction(ER)

Authorization(AZ)

STEP 2 Create an authorization service using the Web Token Service,

Create a WTS with SSL proxy profile and get the processing policy generated with AAA action that has OAuth Client configured earlier,

STEP 3 Create a resource server enforcement point using the Multi-Protocol Gateway,

3 A. Create a front side handler that listens the WTS Authorization service,

3 B. Create a processing policy for the enforcement point having the,

3 C. Choose a static backend type, here it is a simple loopback XML Firewall. Request type as non-xml, Response type as Pass through and propagate URI to on.

Troubleshooting the Configurations,

Scenario 1: Scope not sufficient

Request to invoke WTS Authorization service and get access token,

Curl Command,

curl -k https://<dp:ip>:5050/token -u ac-appln:passw0rd -d “grant_type=client_credentials&scope=getAccount”

Response,

Request with access token to enforcement service to get the response,

Curl Command,

curl -k https://<dp:ip>:5051/getAccount -H “Authorization: Bearer AAEIYWMtYXBwbG5NYwZ3Pi01cM3Rge0qjdvfh4VJ19KCNQoEfkbyiiXvCw9oZLfPdwC7OarGlixMcD46KqjChfuuHB6U/vpL7lWp”

Response,

We get the response as insufficient_scope because URL sent by client is checked for the ER phase for the endpoint server AAA policy, here the scope in the token request includes the leading slash.

Scenario 2: Invalid Client Application

Curl Command,

curl -k https://<dp:ip>:5050/token -d “grant_type=client_credentials&scope=/getAccount&client_id=application&client_secret=passw0rd”

Response,

Scenario 3: Success

Curl Command,

curl -k https://<dp:ip>:5050/token -u ac-appln:passw0rd -d “grant_type=client_credentials&scope=getAccount”

Request to invoke enforcement service(MPG),

curl -k https://<dp:ip>:5051/getAccount -H “Authorization: Bearer AAEIYWMtYXBwbG5NYwZ3Pi01cM3Rge0qjdvfh4VJ19KCNQoEfkbyiiXvCw9oZLfPdwC7OarGlixMcD46KqjChfuuHB6U/vpL7lWp“

Response,

Implementing SLM(Service Level Monitoring) in Datapower

SLM has the ability to monitor traffic and take action if traffic patterns meet certain criteria. For example, consider the case where you have a backend that can only process 300 transactions per second (TPS). SLM can be used to take action when more than 300 TPS inbound transactions are received.

DataPower can be used to ensure this capacity is not exceeded or to send notifications to ensure that any overage is appropriately billed.

DataPower SLM can take action at a transaction threshold in three ways:

Notify: DataPower can send a notification to its logging system via any protocol supported by the device including e-mail, WebSphere MQ, and HTTP. For example, in the case where the REST customer has met its capacity, DataPower could send a notification to a business process that notifies the customer.

Shape: DataPower can delay traffic in an attempt to keep the transaction rate at the given threshold. Take the example where the backend can only process 300 TPS. Here, shaping can be used to queue any transactions that exceed that rate.

Throttle: DataPower can reject transactions that exceed the given threshold.

SLM is supported on multiple appliances that share load with SLM peer groups. The appliances in a peer group continuously communicate with each other to ensure SLM thresholds are shared across the entire group.

A peer group is a collection of DataPower appliances that exchange service level data to enforce SLM policies in the group. A peer group establishes a data-sharing protocol. The traffic that each appliance in the group processes is passed to the other peers to calculate whether a threshold is reached.

Check that all the criteria below is met for creating SLM Peer Group:

1.     All the DataPower Appliances must be clock-synchronized. You can use the NTP service.

2.  The XML Management Interface has to be enabled on both devices.

3. Ensure that there is no firewall in between the appliances blocking the port for the XML Management Interface.

4. Review the XML Management Interface configuration and check the advanced tab, to ensure, the default user agent is not used, or if used, that it has been set up with an SSL Proxy Profile.

5. SLM Peer Groups communicate over XML Management Interface (XMI), and XMI uses SOAP over HTTPS to exchange data. If specifying the “Custom User Agent” property of the XMI and you have an “SLM Peer Group” configured, you must make sure to have an SSL Proxy Profile defined in the “Custom User Agent”.

6. If this was not the case, the outbound request with the “Custom User Agent” property set is not processed by the other appliance in the “SLM Peer Group”.

7. To exchange SLM data at periodic interval, peer members must have identical SLM configurations, including the members list.

8. Ensure that the URLs in the peer group are correct

9. When using hostnames in the peer group URLs, make sure you have a working DNS configuration

10. The SLM policy needs to be identical on both appliances. If they do not match, the peering will not work.

11. SLM Interval length agreement:

An SLM Policy allows administrators to set a threshold level interval set on the SLM Policy Statements page.

When an SLM Policy being enforced by more than one device, administrators must also set a SLM update Interval on the SLM tab of the XML Management Interface configuration page found only in the default domain.

The SLM update Interval must be equal to or less than the threshold interval set in any SLM Policy statement in use on the device. If not, the updates deliver outdated information to the individual policies and are ignored, defeating the purpose of peering.

12. Use the same packet transmission method: unicast or multicast.

13. SLM unicast peering

SLM unicast peering uses unicast packet transmission to update peers in a connected manner.

Consider SLM unicast peering when:

1.     DataPower appliances in the peer group are not physically close or not connected within the same sub network.

2.     The rate of incoming data is low or moderate.

3.     The data sharing interval equals to or is more than one second.

14. SLM multicast peering

SLM multicast peering uses IP multicast packet transmission to update peers in a connectionless manner. Multicast peering supports small threshold intervals and allows data sharing intervals of less than one second.

Consider SLM multicast peering when:

1.     DataPower appliances in the peer group are physically close and connected within the same sub network.

2.     The rate of incoming data is high.

3.     The data sharing interval is less than one second, and you need higher SLM peering accuracy.

4.     The peering traffic and the data traffic use separate networks.

To define a peer group using SLM Unicast:

1.     Click Objects → Network → Peer Groups.

2.     Click Add.

3. In the Name field, enter the name for the configuration.

4. Set Administrative State to identify the administrative state of the configuration.

5. Optional: In the Comments field, enter a descriptive summary.

6. From the Type list, select the type of SLM peering for packet transmission.

7. For SLM unicast peering, specify the IP unicast configuration and update interval to exchange data among peers.

In the URL field, enter the URL of each peer, including the local appliance, and click Add.

8. Click Apply to save the changes to the running configuration.

9. Optional: Click Save Config to save the changes to the startup configuration.

Enable probe in DataPower

Login to DP console  >> > control panel

Click on required services -à Click on Services name

Click on Show Probe button à click on Enable probe.

SOAP Web Service Mockup tutorial on DataPower

It is often the case that a DataPower developer will have work to do, but does  not yet have a backend Service Provider to point the DataPower service at.  In general, anything beyond trivial examples will need to point at something that returns a valid response.  In order to satisfy this requirement, an XML Firewall can be setup in loopback mode that uses a custom stylesheet  to generate a valid response.  This tutorial will demonstrate how to create this XML Firewall.

For our example, we are going to return a valid SOAP response for thisWSDL.

1. Log into the DataPower appliance and navigate to the Control Panel screen if not already there.

1. Click on the XML Firewall icon.

1. Click the “Add Wizard” button.

1. Chose “Pass Thru (Testing Only) radio button.
2. Click the Next button.

1. Type a name for this XML Firewall in the text field.  For this tutorial, we will use MathWS.
2. Click the Next button.

1. Chose “loopback-proxy” from the drop-down menu.
2. Click the Next  button.

1. In the Device Address field, either a valid IP address or Host Alias must be added.  For this example, a Host Alias called PublicInterface, which maps to the public IP address used by one of the ethernet interfaces on this appliance.
2. The Device Port field should have a valid TCP port.  For this example, we are using 10002.
3. For now, SSL will not be used in this example.  So, keep the “off” radio button checked for the last parameter.
4. Click the Next button.

1. This screen lets us review the settings we have chosen in this wizard.
2. Click the Commit button.

1. Click the Done button.

1. Click the save link in the upper, right-hand corner.

1. Click on the XML Firewall icon again.

1. Click on the MathWS link.

1. In the right-hand column, at the bottom, choose “XML” from the Request Type dropdown menu.
2. Click the Apply button.
3. Click the Advanced tab link.

1. In the left-hand column, click the off radio button under “Disallow GET (and HEAD)”. 
2. In the right-hand column, click the on radio button under “Process Messages Whose Body IS Empty”.
3. Click Apply.
4. Click the save config link.

1. Next, we need to create an XSLT stylesheet that will return a static response to SOAP queries.  As a starting point, copy the contents of the stylesheet given in this tutorial into your favorite XML editor.
2. So, you should now have the following in your XML editor:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:dp="http://www.datapower.com/extensions"
    xmlns:dpfunc="http://www.datapower.com/extensions/functions"
    xmlns:dpconfig="http://www.datapower.com/param/config"
    xmlns:func="http://exslt.org/functions"
    extension-element-prefixes="dp func"
    exclude-result-prefixes="dp dpfunc dpconfig func"> 
   
    <xsl:template match="/">  
       
    </xsl:template>
</xsl:stylesheet>

Next, we need to generate a valid SOAP response.   This can be done with SOAPUI.

Download the WSDL to your local file system.

Download SOAPUI or a similar tool.

Launch SOAPUI.

 

Click File->New SOAPUI Project.

Enter “MathWS” in the Project Name field.

Click the browse button.

Choose the MathWS.wsdl file that was selected earlier.

Click Ok.

After some processing, a project will be created.

Expand the MathWS->MathWSSoapBinding->sum->Request 1 tree.

Double-click on the Request 1 node.

You will see a request message with ‘?’s in place of values.

Click  the SOAP icon (third icon from the left) on the Request 1 window.

The following pop up box will appear.

Click the Yes button.

Enter a name for the Mock Service.

Click the Ok button.

When prompted for “Open MockResponse editor?”, click the Yes button.

We now have a valid SOAP response that can be added to our new stylesheet.

Copy the text in the Response1 window into the <template> of the stylesheet.

Replace the ‘?’ with ‘6’ or your favorite number.

The stylesheet should now look like:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:dp="http://www.datapower.com/extensions"
    xmlns:dpfunc="http://www.datapower.com/extensions/functions"
    xmlns:dpconfig="http://www.datapower.com/param/config"
    xmlns:func="http://exslt.org/functions"
    extension-element-prefixes="dp func"
    exclude-result-prefixes="dp dpfunc dpconfig func"> 
   
    <xsl:template match="/"> 
        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:ws="http://ws.rcbj.com/">
            <soapenv:Header/>
            <soapenv:Body>
                <ws:sumResponse>
                    <return>6</return>
                </ws:sumResponse>
            </soapenv:Body>
        </soapenv:Envelope>
    </xsl:template>
</xsl:stylesheet>

Save this file as MathWS-Response.xslt on your local file system.

Navigate back to the DataPower Control Panel in your browser.

Click on the File Management icon.

Click the Actions link next to local:///.

Choose the “Create Subdirectory” option.

Enter a meaningful directory name.  This tutorial will use “example”.

Click the “Confirm Create” button.

Expand the local: directory. 

You should see a subdirectory called example.

Click the “Actions.” link next to the example subdirectory.

Chose “Upload Files” link.

Click the “Choose File” button.

Select the MathWS-Response.xslt file.

The “Save As:” field should be automatically filled in with “MathWS-Response.xslt”.

Select the “Overwrite Existing Files” checkbox.

Click Upload button.

Click the Continue button.

Navigate back to the MathWS XML Firewall configuration screen.

Click on the “.” button below “XML Firewall Policy” on the right-hand side.

Expand this window to give yourself more room to work.

Find the round icon in the large window towards the bottom marked “Transform”.

Drag this Transform Action icon onto the Request Rule between the diamond shaped Match Action and the square shaped Response Action.

Double-click the the yellow highlighted Transform Action.

From the Transform drop-down menu that currently shows “local:///”, chose “local:///example”.

From the file drop down directly below it, chose the MathWS-Response.xslt file.

All other fields can be left as their default values.

Click the Done button.

Click the “Apply Policy” button.

Click the Close Window link.

Click the Apply button.

Click the Save Config link.

Now, return to the SOAPUI project that was created earlier.

Go to the “Request 1″ screen.

We need to replace the two ‘?’ with integers.  I am going to use ‘2’ and ‘4’.  So, the request now looks like:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:ws="http://ws.rcbj.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:sum>
         <arg0>2</arg0>
         <arg1>4</arg1>
      </ws:sum>
   </soapenv:Body>
</soapenv:Envelope>

Modify the service URL to behttp://dp2.rcbjconsulting.com:10002/service/MathWS (choose edit current from the drop down menu).  Replace the URL with whatever is a valid URL for your appliance.

Click the Execute button.

A response containing the following should come back:

<soapenv:Envelope xmlns:ws="http://ws.rcbj.com/"xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:sumResponse>
         <return>6</return>
      </ws:sumResponse>
   </soapenv:Body>
</soapenv:Envelope>

You have successfully constructed a “dummy service” that can be used in the absence of a legitimate Service Provider implementation.

XI50 to XI50 Data Power Migration

Here are steps: 
1 Check and upgrade the firmware version and level of DataPower XI50 to that of the firm-ware version and level of the DataPower XI52. 
2 Secure backup XI50 
4 Secure backup XI52; this might be useful in case if you need to rollback to original con-figurations. Also export configurations from XI52; this would be used later for referring for resetting various configurations. 
5 Validate and then restore DataPower XI52 from the secure backup files from the Data-Power XI50 
6 Access DataPower XI52 via remote console and update 
a. IP interface to have its own IPs. The Ethernet Interface names are different on XI52 appliances; need to reconfigure the eth settings 
b. host alias 
c. system info 
d. ip routing 

7 Test restored Datapower XI52 
a. That the DataPower is accessible using its own IPs. Test login through WebGUI and CLI. 
b. Compare objects on the DataPower XI52 against the objects on the DataPower XI50 that they are up and running.