Implementing a Data Diode with WSO2 ESB

Data Diode is the data pattern that ensures unidirectional data flow between networks and is useful for enterprises who want to connect networks with different security levels. This patterns will be used to ensure that data is only allowed to flow from the low side (low security network) to high side (high security network). This type of a dataflow, in most cases is controlled at the network level, but if a need arise to control this at a data layer this EIP pattern can be used. Let’s look at the image below

Diode

As you can see in this diagram, two WSO2 ESB’s reside on two sides of the network. The ESB in the unsecure network is connected to different applications in the unsecured network. It also connects to the ESB in the secure network and the communication is encrypted (if needed integrity and non-repudiation can also be ensured) using WS-Security.

The ESB in the secure network has all its outbound transports (except JMS transport) removed, hence the ESB can only receive messages from the unsecured network whilst it can only send out messages to a pre-designated message queue.

Consumers of this data can listen to the queue and pull messages from the queue once they are queued.

Setting up the ESB to work in this pattern would require the execution of following steps

  1. Remove/Disable all out-going transports except the JMS and local transport. This can be done by disabling/removing all transportSenders from the following configuration file.
<>\repository\conf\axis2\axis2.xml

The transportSender section of the configuration file should only have the two transports below.

<transportSender name="local" class="org.wso2.carbon.core.transports.local.CarbonLocalTransportSender"/>
<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>
  1. Configure a message queue, you can configure a JMS or AMQP based message queue. More instruction on how to configure the queue can be found in the following link

https://docs.wso2.com/display/ESB481/ESB+as+a+JMS+Producer

  1. Create a Proxy service as given below.

  1. Finally Secure the proxy service, you can follow the instructions below to secure a proxy service using the WSO2 ESB.

https://docs.wso2.com/display/ESB481/Securing+Proxy+Services

You can now try to invoke the DiodeProxy from the unsecure network, you will notice that no response would be received back from this proxy. Even if a new proxy service is created in the secured ESB, the communication would still be blocked by the ESB as all but the JMS is blocked in the secured ESB.

Advertisements

SSL Mutual Authentication with WSO2 ESB

SSL Mutual authentication is a widely used authentication mechanism in B2B communication. This blog looks at the concept of SSL mutual authentication and how WSO2 ESB can support SSL Mutual authentication.

How mutual authentication works can be depicted in the diagram below

mutualAuth

1. Client Request a resource from the server

2. Server presents the certificate

3. Client validates the certificate from the trust-store

4. Client present its certificate to the server

5. Server validates the certificate with the trust-store

6. Client access the protected resource

For this example we are using the mutual authentication client developed by Asela, and we will be creating our own KeyStore and a TrustStore (we will be using a single key store as both the KeyStore and the TrustStore) for the client service.

1. Lets start by modify the following {ESB_home}/repository/conf/axis2/axis2.xml file by un-commenting the following line in the ‘PassThroughHttpSSLListener’ transport receiver.

<parameter name="SSLVerifyClient">require</parameter>

2. Lets create the KeyStore for the client. We will be using the Java Keytool library for this. We will be executing the following command to create the keystore.

keytool -genkey -alias Client -keyalg RSA -keystore clientKeyStore.jks -keysize 2048

Keytool will prompt the user to enter a keystore password and other values pertaining to the keystore, enter these values and create the keystore. If you go to the folder from which you executed this command you will see the newly created keystore.

3. Next lets export a public certificate from the client Keystore that we can share with the ESB. To do this lets execute the following command.

keytool -export -keystore clientKeyStore.jks -alias Client -file client.crt

You will be prompted to enter the keystore password, enter the password you entered in the step1 .You will now see the client.crt file been created in the folder

4. We will be using the default WSO2Carbon keystore in the ESB, so lets create a public certificate from the wso2carbon keystore to be shared with the client. To do this execute the command below from the following location {ESB_Home}\repository\resources\security

keytool -export -keystore wso2carbon.jks -alias wso2carbon -file ESB.crt

You will prompted to enter the password of the keystore, enter ‘wso2carbon’ which is the default password.

5. Lets now import the certificates to each other’s trust store. Since we are using the same store as the keystore and the truststore for the client lets import the ESB certificate by executing the below command. (this command assume that both the client keystore and the ESB’s public certificate in the same folder)

keytool -import -keystore clientKeyStore.jks -alias wso2carbon -file ESB.crt

You will need to enter the client keystore password you entered in step1. You will also need to confirm the importing of the certificate to the keystore

6. Lets now import the clients certificate to the ESB. To do this execute the following command.

keytool -import -keystore client-truststore.jks -alias Client -file client.crt

As before you will need to enter the client-truststore password which is ‘wso2carbon’ and you would be prompted to add the certificate to the keystore. Once you approve the addition, the certificate would be added to the keystore.

7. Now lets invoke the MutualSSL client[1], for this client to work as we have configure the keystore name, the keystore password which we have set in step1, and the client keystore location. You will also need to provide the service URL of the secured service in the ESB.  Once this is set build the MutualSSLClient using maven. After the build is complete you will see the relevant jar file in the target folder. You can run this jar file from the WSO2 Application Server by following the information here [2]. You can use the try it client in WSO2 Application Server or a SOAP client to test the MutualSSLAuthentication client.

You would see the response from the service in the client

[1] https://svn.wso2.org/repos/wso2/people/asela/ssl/MutualAuthenticationClient/

[2] https://docs.wso2.com/display/AS521/Jar+Services

Restricting grant types for an application in WSO2 API Manager

WSO2 API Manager has the capability of restricting which grant types are enabled to a given application. This functionality is provided via the management console of the API Manager. Given below are the steps required

1. App developers should have the required permission in order to restrict the grant types available for an application. Permission given below should be set to a user role associate to the App developer.

2. Once this is done please log out and log into the API Manager’s admin console

3. Now you would see the OAuth URL available in the left navigation, click on this.

4. Here you would see all the applications that are created by the App developer, from this menu select the relevant application to which the grant types should be restricted.

5. Once you are inside the selected application you can define which grant types should be allowed to a given application. By default all grant types are ‘un-checked’ and all grant types are allowed. If you want to override this default configuration select on the required grant types that should be allowed to a given application.

6. Once you are done click on the update button and the configuration would be updated.

IP based filtering for Proxy services exposed by WSO2 ESB

WSO2 ESB provides the ability to filter messages based on different parameters. These parameters include data in the message header, message content or even data relating to the message sender. This blog looks into how WSO2 ESB can be used to filter a message based on the IP Address of a client. The below ESB configuration would filter a message and send it to the beackend service only if it arrives from a pre-defined IP address range (192.168.1.*). If the message is recieved from any other IP address the message is dropped. This type of IP based filtering can be applied to secure a backend service from unauthorized access.

How to retrieve token information using REST API in WSO2 API Manager

WSO2 API Manager provides a host of REST API’s that are capable of performing many operations in the API Manager. Given below are the steps to follow to retrieve token information such as the Consumer Key,Consumer Secret, and Access Token using the REST API. In order to perform this we assume that an instance of the API Manager is running(in port offset 0) and an application is already available in the API Store.

1. Initially you need to login to the API Store and create a cookie that can be used in subsequent REST calls. Login to the store using the following command. Replace the username and the password with the relavent value

curl -X POST -c cookies http://localhost:9763/store/site/blocks/user/login/ajax/login.jag -d "action=login&username=xxxx&password=xxxx"

2. Call the Generate Application Key API that would generate the required access keys. Use the below command to generate the application keys. The following command would generate keys for the default applications. Change the parameters accordingly based on your application.

curl -X POST -b cookies http://localhost:9763/store/site/blocks/subscription/subscription-add/ajax/subscription-add.jag -d "action=generateApplicationKey&application=DefaultApplication&keytype=PRODUCTION&provider=&tier=&version=&callbackUrl=&authorizedDomains="

Mounting WSO2 instances on a MS SQL Database which is secured via Windows authentication

A multi instance deployment of WSO2 products would require the registry (config and governance) space to be mounted on an external database.  WSO2 Products can be mounted on many types of databases. Below instructions explain how WSO2 products can be mounted on a MS SQL database that is secured via Windows Authentication.

  1. download jTDS from the following link

http://sourceforge.net/projects/jtds/files/jtds/1.2.2/

  1. Extract the folder and copy the jtds-1.2.2.Jarfile to the {WSO2 Product}/components/lib folder
  1. The extracted folder also includes ntlmauth.dllfile in the \x64\SSOfolder copy the dll file to java bin folder(C:\Program Files\Java\jre7\bin)
  1. download and install the jdbc driver for mssql from the following location

http://msdn.microsoft.com/en-us/sqlserver/aa937724.aspx

  1. Once this is installed set the class path to the following location {JDBC driver Installation Path}\sqljdbc_4.0\enu\auth\x86
  1. Make sure that the IP and the port is enabled at the MSSQL side, this can be verified through telnet.
  1. Change the datasources.xml to the following configuration (Please change the DB name and the hostname accordingly)

  1. Start the ESB.