Wednesday, May 14, 2014

Secure, Expose and Manage a SOAP Service using WSO2 API Manager and WSO2 ESB.



WSO2 API Manager provides support for both REST and SOAP based web services. However the API Manager doesn’t support WS Standards. The API Manager and the WSO2 ESB can be used in conjunction to support WS Standards to API’s exposed via the API Manager. In this blog we look at how WSO2 API Manager can be used with the WSO2 ESB to secure and expose a SOAP based API.

Given below is a diagram depicting the message flow on how WS-Security is implemented using WSO2 API manager and WSO2 ESB.


The message from the client would be encrypted using the public key of the ESB. The encrypted message would be sent along with the acquired OAuth token to the API Manager. The API Manager would validate the OAuth token and enforce throttling on the message. The API Manager would send the encrypted message to the ESB. The ESB would decrypt the content of the message using its own private key and send the request to the backend service.

Once the response is received from the backend service, the ESB would encrypt the message using client’s public key and send it to the API Manager. The API Manager would pass-through the message back to the client. The client would decrypt the message using its own private key.

This type of a scenario is useful in a case where
1.WS-Security needs to be enforced but cannot be enforced directly at the backend service (hence needs be enforced in an intermediary stage in the message flow).
2. Client should be provided with a portal to explore and subscribe to API’s.
3. API Publisher wants to manage life-cycle and manage API versioning of the exposed API’s.
4. Throttling and other security mechanisms has to be enforced on-top of WS-Security.
5. Statistics on API invocations needs to be gathered.



Thursday, April 3, 2014

Using WSO2 ESB to modify messages with text content

WSO2 ESB provides 1st class support to SOAP and REST message formats. The WSO2 ESB is also capable of mediating messages with plain text contents. This can be done using a script mediator. You can read more about the script mediator from this link[1]. For this scenario I would be sending a text payload over HTTP. The ESB would extract the message payload and perform text manipulation using the script mediator and send the modified payload to the backend service. The script used in the script mediator is Javascripts. The following diagram illustrates the message flow.


Given below is a sample synapse configuration for the scenario. In the example below HTTP POST with a payload "Text send by Nadeesha" is sent to the ESB, which would be replaced as "Text from Nadeesha" and sent to the backend service.

<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="testProxy"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <log level="full"/>
         <log>
            <property xmlns:m0="http://ws.apache.org/commons/ns/payload"
                      name="payload"
                      expression="$body/m0:text"/>
         </log>
         <property xmlns:m0="http://ws.apache.org/commons/ns/payload"
                   name="payload"
                   expression="$body/m0:text"/>
         <script language="js">var payload= mc.getProperty('payload').trim();var newPayload= payload.replace("send by","from");mc.setProperty("newPayload",newPayload);</script>
         <enrich>
            <source type="property" clone="true" property="newPayload"/>
            <target type="body"/>
         </enrich>
         <log level="full"/>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
      <endpoint>
         <address uri="http://localhost/testEP"/>
      </endpoint>
   </target>
   <description/>
</proxy>


The same functionality can also be done using a class mediator where by a Java class can be written to perform the same task.

[1] https://docs.wso2.org/display/ESB481/Script+Mediator

Thursday, March 20, 2014

Integrating WSO2 API Manager with a 3rd Party Billing tool

How can we integrate 3rd party billing to the WSO2 API Manager? 
The API Manager already collects all API related data when an API invocation is made by a service consumer. The API Manager can publish them to the WSO2 Business Activity Monitor (WSO2 BAM) out of the box, which the WSO2 BAM uses to generate information required for API statistics. The same process can be utilized by a 3rd party tool to access API information from the API Manager. Once the data is published to the WSO2 BAM, WSO2 BAM would stores the data in a Cassandra data-store and summarize these data periodically based on a set of Apache Hive queries. The summarized information can then be inserted to a RDBMS which can be accessed by the 3rd party billing tool. This can be illustrated by the diagram below

The WSO2 API Manager is shipped with a standard set of Hive queries(As part of the BAM toolbox) to summarize API data. It is possible to modify or write your own Hive queries to summarize the API information based on your own KPI's to fit the needs of the 3rd party billing system. The billing system can directly access the RDBMS and use it as a data source to generate billing information.

Wednesday, March 5, 2014

Metadata relationship in WSO2 Governance Registry

Given the different metadata types available in WSO2 Governance Registry, it adds a great amount of confusion to understand how these are related to each other. Let me explain it through the simple diagram below




Saturday, January 11, 2014

Managing the WSO2 API Manager via JMX in 3 easy steps

WSO2 API Manager provides multiple ways in measuring the performance of its server runtime. The server performance can be measured by the management console of the API Manager. Alternative to this the server runtime performance can also be monitored remotely through a JMX client such as JConsole.
Given below are the steps required to configure the performance monitoring of the API Manager via JMX.
1. On the API Manager Server startup you would find the JMX server URL as below.
JMX Service URL  : service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi
This URL allows the JMX endpoint of the WSO2 API Manager to be accessed remotely.
2. Start JConsole, JConsole can be found in JDK_HOME/bin folder. JConsole can be started by typing jconsole in the Shell/Command prompt.

3. In the JConsole ‘New Connection’ page enter the above JMX service URL of the API Manager along with the admin username and the password as shown below. Once this is done click on the connect button.



Now you would be able to see statistics relating to the WSO2 API Manager Server runtime in the JConsole.

Sunday, November 24, 2013

WSO2 Deployment synchronization on Windows environment

Deployment synchronization (dep-sync) is a feature that is shipped with most of the WSO2 products. This blog looks at how deployment synchronization can be achieved on carbon instances running on windows environment.

1.      Deployment synchronization requires SVNKit implementation from http://dist.wso2.org/tools/svnClientBundle-1.0.0.jar. This library has to be downloaded separately since it is not shipped with the WSO2 distribution.

2.      Once this SVN kit is downloaded copy the svnClientBundle-1.0.0.jar to {carbon_home}\repository\components\dropins folder on all the instances that artifacts need to be synchronized.

3.      In the Manager node open the {carbon_home}\repository\conf\carbon.xml and enable the dep-sync configuration as given below

     <DeploymentSynchronizer>
        <Enabled>true</Enabled>
        <AutoCommit>true</AutoCommit>
        <AutoCheckout>true</AutoCheckout>
        <RepositoryType>svn</RepositoryType>
        <SvnUrl>SVN URL</SvnUrl>
        <SvnUser>username</SvnUser>
        <SvnPassword>password</SvnPassword>
        <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
    </DeploymentSynchronizer>

4.      In the worker nodes use the following configuration to enable dep-sync in the {carbon_home}\repository\conf\carbon.xml file.
     
    <DeploymentSynchronizer>
        <Enabled>true</Enabled>
        <AutoCommit>false</AutoCommit>
        <AutoCheckout>true</AutoCheckout>
        <RepositoryType>svn</RepositoryType>
        <SvnUrl>SVN URL</SvnUrl>
        <SvnUser>username</SvnUser>
        <SvnPassword>password</SvnPassword>
        <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
    </DeploymentSynchronizer>

5.      Enable clustering in all instances by setting the clustering value as true in the {carbon_home}\repository\conf\axis2\axis2.xml.
<clustering class="org.apache.axis2.clustering.tribes.TribesClusteringAgent" enable="true">

Once the clustering is enabled, set a domain name so that all instances in the cluster will have the same domain name. Domain can be set as shown below.
 <parameter name="domain">wso2.carbon.domain</parameter>

Friday, November 22, 2013

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

2. Extract the folder and copy the jtds-1.2.2.Jar file to the {WSO2 Product}/components/lib folder

3. The extracted folder also includes ntlmauth.dll file in the \x64\SSO folder copy the dll file to java bin folder(C:\Program Files\Java\jre7\bin)

4. download and install the jdbc driver for mssql from the following location 

5. Once this is installed set the class path to the following location {JDBC driver Installation Path}\sqljdbc_4.0\enu\auth\x86

6. Make sure that the IP and the port is enabled at the MSSQL side, this can be verified through telnet.

7. Change the datasources.xml to the following configuration (Please change the DB name and the hostname accordingly)

<datasource>
<name>WSO2_CARBON_DB</name>
<description>The datasource used for registry and user manager</description>
<jndiConfig>
   <name>jdbc/WSO2CarbonDB</name>
</jndiConfig>
<definition type="RDBMS">
   <configuration>
<url>jdbc:jtds:sqlserver://localhost:1433/testDB;integratedSecurity=true;</url>
<driverClassName>net.sourceforge.jtds.jdbc.Driver</driverClassName>
<maxActive>80</maxActive>
<maxWait>60000</maxWait>
<minIdle>5</minIdle>
<testOnBorrow>true</testOnBorrow>
<validationQuery>SELECT 1</validationQuery>
<validationInterval>30000</validationInterval>
   </configuration>
</definition>
</datasource>

8. Start the ESB.