This documentation is for WSO2 ESB version 4.7.0. View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

Using a Basic Auth Handler

In most of the real-world use cases of REST, when a consumer attempts to access a privileged resource, credentials must be provided in an Authorization header or the consumer will be refused access. In WSO2 ESB, when we want to secure a REST API, we can simply make it available via HTTPS and let the security handlers validate the credentials. By default, the ESB does not include any REST Security Handlers, but the following example of a primitive security handler serves as a template can can use to write your own security handler to secure a REST API in the ESB.

You add the REST request handler to the <handlers> element of the API configuration, as follows (you cannot add it through the REST API UI):

The custom Basic Auth handler in this sample simply verifies whether the request uses username: admin and password: admin. Following is the code for this handler:

You can build the project (mvn clean install) for this handler by accessing its source here:

https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/products/esb/4.7.0/modules/samples/integration-scenarios/starbucks_sample/BasicAuth-handler

Alternatively, you can download the JAR file from the following location, copy it to the repository/component/lib directory, and restart the ESB:

https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/products/esb/4.7.0/modules/samples/integration-scenarios/starbucks_sample/bin/WSO2-REST-BasicAuth-Handler-1.0-SNAPSHOT.jar

You can now send a request to the secured API. For example, you can send it using cURL as the REST client:

curl -v -k -H "Authorization: Basic YWRtaW46YWRtaW4="  https://localhost:8243/stockquote/view/IBM

Using an OAuth Base Security Token

You can generate an OAuth base security token using WSO2 Identity Server, and then use that token when invoking your REST API to connect to a REST endpoint. This approach involves the following tasks:

  1. Create a custom handler that will validate the token
  2. Create a REST API that points to the REST endpoint and includes the custom handler
  3. Create an OAuth application in Identity Server and get the access token
  4. Invoke the API with the access token

Creating the Custom Handler

The custom handler must extend AbstractHandler and implement ManagedLifecycle as shown in the following example. You can download the Maven project for this example at: http://www.mediafire.com/?7bm8g5br76w10rw

Creating the API

You will now create a REST API named TestGoogle that connects to the following endpoint: https://www.google.lk/search?q=wso2

  1. In the ESB Management Console, go to Manage -> Service Bus and click Source View.
  2. Insert the following XML configuration into the source view before the closing </definitions> tag to create the TestGoogle API:

    Notice that the <handlers> tag contains the reference to the custom handler class.

  3. Copy the custom handler.jar to the <ESB_HOME>/repository/components/libs directory.
  4. Open <ESB_HOME>/repository/conf/axis2/axis2.xml and add the following parameters:

  5. Restart the ESB.

Getting the OAuth Token

You will now use Identity Server to create an OAuth application and generate the security token.

  1. Start WSO2 Identity Server and log into the management console.
  2. Click Manage -> OAuth and create an OAuth application.
  3. Note the access token URL and embed it in a cURL request to get the token. For example, use the following command and replace <client-id> and <client secret> with the actual values:

    curl -v -X POST --user <client-id>:<client secret> -H "Content-Type: application/x-w ww-form-urlencoded;charset=UTF-8" -k -d "grant_type=password&username=admin&password=admin" https://localhost:9448/oauth2/token

Identity Server returns the access token, which you can now use when invoking the API. For example:

curl -v -X GET -H “Authorization: Bearer ca1799fc84986bd87c120ba499838a7″ http://10.100.1.198:8280/search

Using a Policy File to Authenticate with a Secured Back-End Service

You can connect a REST client to a secured back-end service (such as a SOAP service) through a REST API that reads from a policy file.

 

First, you configure the ESB to expose the REST API to the REST client. For example:

The policy file stores the security parameters that are going to authenticated by the back-end service. You specify the policy file with the localEntry property, which in this example we've named sec_policy:

You use then reference the policy file by its localEntry name when enabling the security policy for the end point:

In the outSequence property, the security header must be removed before sending the response back to the REST client.  

To test this REST API configuration, you must run the SecureStockQuoteService, which is bundled in the WSO2 ESB samples folder, as the back-end server  . Start this sample as described in ESB Samples Setup. Because this sample uses Apache Rampart for the back-end security implementation, you might also need to download and install the unlimited strength policy files for your JDK before using Apache Rampart.

To download the unlimited strength policy files:

  1. Go to http://www.oracle.com/technetwork/java/javase/downloads/index.html .
  2. Scroll to the bottom of the page and download the file called Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files x (x is the JDK version) for your JDK version.
  3. E xtract the downloaded ZIP. You’ll now have two JAR files: local_policy.jar and US_export_policy.jar.
  4. In your Java installation directory, go to the jre/lib/security directory, such as: / usr/java/jdk1.6.0_38/jre/lib/security
  5. M ake a backup of the files local_policy.jar and US_export_policy.jar and then replace them with the ones from the JCE ZIP file.

Now that you have set up the REST API and the secured back-end SOAP service, you are ready to test this configuration with the following curl command.  

  curl -v http://127.0.0.1:8280/stockquote/view/IBM  

Observe that the REST client is getting the correct response (the wsse:Security header is removed from the decrypted message) while going through the secured back-end service and the REST API implemented in the ESB. You can use a TCP monitoring tool such as tcpmon to monitor the message sent from the ESB and the response message received by the ESB.   For a tutorial on using tcpmon, see:   http://technonstop.com/tcpmon-tutorial
 

Transforming Basic Auth to WS-Security

REST clients typically use Basic Auth over HTTP to authenticate the user name and password, but if the back-end service uses WS-Security, you can configure the REST API to transform the authentication from Basic Auth to WS-Security.

To achieve this transformation, you configure the ESB to expose the REST API to the REST client as shown in the previous example, but you add the HTTPS protocol and Basic Auth handler to the configuration as shown below:

<?xml version="1.0" encoding="UTF-8"?>

<definitions xmlns="http://ws.apache.org/ns/synapse">

   <localEntry key="sec_policy"

            src="file:repository/samples/resources/policy/policy_3.xml"/>

   <api name="StockQuoteAPI" context="/stockquote">

      <resource methods="GET" uri-template="/view/{symbol}" protocol="https">

...

 

      </resource>    

 

      <handlers>

 

        <handler class="org.wso2.rest.BasicAuthHandler"/>

 

      </handlers>

   </api>

 </definitions>

This configuration allows two-fold security: the client authenticates with the REST API using Basic Auth over HTTPS, and then the REST API sends the request to the back-end service using the security policy. 

You can test this configuration using the following command:

curl -v -k -H "Authorization: Basic YWRtaW46YWRtaW4=" https://localhost:8243/stockquote/view/IBM
 

Labels
  • None