Use of SSL Profiles in WSO2 ESB

SSL profiles in WSO2 ESB allows you to use different trust stores/ key stores for different hosts. For example you will have couple of hosts that requires 1-way SSL (SSL-client is not verified by the server. Only server is verified by the client.) and another host requiring 2-way SSL (Mutual SSL - it is a certificate based authentication where two parties [client and server] authenticate each other by verifying digital certificates. So in simple terms both parties are assured of other's identity.).

In here I have given an example where ESB acting as the server. 1-way SSL requires only key store in it's configuration. For mutual SSL you need to configure both trust store and the key store. In ESB we can have 2 different SSL profiles to support the above mentioned scenario. One profile for hosts requiring only 1-way SSL and another profile for the host requiring mutual SSL.

How to configure SSL profiles in WSO2 ESB.

Open  <ESB_HOME>/repository/conf/Axis2/axis2.xml. Edit <transportReceiver> configurations as follows. (If ESB is acting as the client you have to edit <transportSender> configurations to add customSSLProfiles.)

<transportReceiver name="multi-https" class="org.apache.synapse.transport.nhttp.HttpCoreNIOMultiSSLListener">

        <parameter name="port">8343</parameter>

        <parameter name="non-blocking">true</parameter>

        <parameter name="SSLProfiles">

            <profile>

                <bindAddress>localhost:9445, localhost:9446</bindAddress>

                <KeyStore>

                    <Location>/path/to/keystore1.p12</Location>

                    <Type>PKCS12</Type>

                    <Password>key1</Password>

                    <KeyPassword>key1</KeyPassword>

                </KeyStore>

            </profile>

           <profile>

                <bindAddress>localhost:9455</bindAddress>

                <KeyStore>

                    <Location>/path/to/keystore2.p12</Location>

                    <Type>JKS</Type>

                    <Password>test</Password>

                    <KeyPassword>test</KeyPassword>

                </KeyStore>

                <TrustStore>

                    <Location>/path/to/trustStore2.jks</Location>

                    <Type>JKS</Type>

                    <Password>test</Password>

                </TrustStore>

                <SSLVerifyClient>require</SSLVerifyClient>

            </profile>

        </parameter>

</transportReceiver>

 As you can see 1st profile contains only key store. And it has 2 bind addresses. That means hosts running on localhost:9445 and localhost:9446 will use this profile for their SSL authentication.

2nd profile has both key store and trust store configurations. And also it has <SSLVerifyClient>require</SSLVerifyClient> parameter added to the configuration. That is used to enable mutual SSL. This profile will be used for host running on 9445 port. Like wise we can have multiple SSL profiles for different hosts and also we can have same profile for different hosts. This is useful when you have many proxy services or APIs running on your WSO2 ESB.

Configure ciphers in WSO2 Servers to establish secure connections.

Cipher suites are encryption algorithms which are used to establish secure communication between host and the client. However cipher suites can be classified in to different categories based on the level of security they provide. Some ciphers are capable of providing better security compared to others. So sometimes you will need to customize the ciphers that your server should support in order to have a better secure connection.

These supported ciphers can be given to any wso2 server. To test the supported ciphers, first download TestSSLServer.jar from here http://www.bolet.org/TestSSLServer/TestSSLServer.jar. It is a command line tool which contacts a SSL/TLS server and provide information on supported protocols and supported cipher suites. 

Then start a WSO2 server and normally server will start from port 9443.

Go to TestSSLServer.jar location from command line and list supported protocols and ciphers using this command.
java -jar TestSSLServer.jar localhost 9443

Then you can see a list like this.

Then again shut down the server and go to <product-home>/repository/conf/tomcat folder and open catalina-server.xml. Find the relevant connector configuration with SSL/TLS configurations. Add another field as ciphers and give preferred cipher list in a comma separated manner.

EX:

<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" 

port="9443"  

bindOnInit="false" 

sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"  

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"

Here I have given only two ciphers.

Then again start the server and list supported protocols. There you can see only the given ciphers are supported by the server.

Server will accept requests from clients supporting these given protocols. If client does not support given sslEnabledProtocols or ciphers, server will not establish a secure client/server connection.

Guidelines for OBD Reader Android Application Development

OBD adapter is an electronic device that allows a computer to access the vehicle network through its ECU (Engine Control Unit). OBD2 adapter can be plugged into the OBD2 ports (Data Link Connector (DLC)) in a vehicle. Data coming from the ECU can be retrieved from an android application via Bluetooth connection. OBD2 provides real time data.

Data flows both ways through OBD2 to and from the ECU. This will be the flow of data

1.  Mobile application sends request to the OBD adapter via Bluetooth interface (AT commands).
2. OBD2 adapter receives the request.
3. OBD2 retransmits the request to the ECU on one of the OBD protocols
4. ECU responds back with the data to OBD2.
5. OBD2 sends data to the mobile application.

A protocol is used for the communication between OBD device and android application. It is text based polling type protocol. That means you should send commands as requests in order to get a response. 

OBDSim

Since it is not possible always to test OBD2 related applications in a real environment with a vehicle there are existing application which has the capability to simulate a vehicle with an OBD device plugged in.

OBDSim is one such simulator which we have used to test our mobile application. This is a cross platform and works on Windows/ Linux software platforms. Similar to ELM327 OBD2 adapter this also works on AT commands which are used to configure an ELM327.

Installing OBDSim

You can download it from this link http://icculus.org/obdgpslogger/.

Useful links to set up OBDSim

1. http://stackoverflow.com/questions/13164150/obd2-elm327-bluetooth-simulator?lq=1
2.  http://stackoverflow.com/questions/21957505/connect-obdsim-to-torque-on-windows-through-bluetooth
3. http://stackoverflow.com/questions/25720469/connect-obdsim-to-torqueandroid-app-ubuntu/25763606#25763606

After installing and running the OBDSim we can manually change the parameters and test our application.

Developing Android Application

Application should be capable of performing following functionalities.

• Connect to OBD device through its Bluetooth interface.

• Initialize OBD adapter with AT commands.

o   AT SP 0 - This is to set the protocol to “AUTO”. That means we want the interface to automatically detect the protocol when we send the first OBD request. If it is successful reply will be “OK”.

o   AT DP - To verify the protocol (Display Protocol). Reply – “AUTO

•      Continuously retrieve data from OBD adapter.

We have to use OBD-II Parameter IDs (On-Board Diagnostics Parameter IDs - PIDs) in order to communicate with the vehicle. Those individual PIDs provide some specific information on vehicular data. 

OBD-II PIDs (On-Board Diagnostics Parameter IDs) are codes used to request data from a vehicle. There is a standard set of PIDs which is defined by SAE standard J/1979. Other than that, manufacturers define their own PIDs.

Process of communication through PIDs.

1.  Mobile application sends PID s as requests to the OBD2 adapter.

2. OBD2 device sends it to the vehicle’s controller area network (CAN).

3.  A device on the bus recognizes the PID as one it is responsible for, and reports the  value for that PID to the bus.
4. OBD2 reads the response and send it back to the mobile application.

 Example PID s that are sent to get speed and RPM.

           o   010C – Get RPM. Example reply – “41 0C 0F A0”. The reply contains two bytes that identify it as a response to Mode 1, PID 0C request (41 0C), and two more bytes with the encoded RPM value (1/4 RPM per bit). To get the actual RPM value, convert the hex number to decimal, and divide it by four: 

                                                     0x0FA = 4000

                                                     4000/4 = 1000 rpm

o   010D – Get vehicle speed.  Reply – 41 0D FF. To get the speed have to convert this to decimal.

Crowdsourced traffic data analysis and visualizing using WSO2 CEP.

Introduction

Aim was to develop a mobile application and a website to get reliable traffic data in certain areas. GPS data received from smart phones of users was analyzed via CEP. When the users log into the android application their GPS data was sent to the CEP. From the data received, it was possible identify the location and moving speeds of users. Analyzing the traffic condition was done inside CEP. After analyzing, crowd sourced data about traffic is displayed on a map. 

Usage of geo-fencing and level of service to calculate traffic

Geo fencing is a feature that can be used in a software program to define the geometrical boundaries. In our project this technology was used to segment the road. Geo-fencing custom extension in WSO2 CEP is used to define the boundaries and filter vehicular data. When CEP receives an event, its coordinates are checked against the defined boundaries to check whether it is inside or outside, using OSGeo Geo Tools library [1].

We used the method Average Travel Speed (ATS) to calculate traffic level of service.

ATS = Distance / average time of vehicles

One execution plan includes all the required processes to calculate the traffic status of a particular road segment. 

User’s imei number, longitude, latitude values were passed in to the execution plan from an event stream.

In the execution plan two polygons in one junction were defined using longitude and latitude coordinates of the road segments. When CEP receives an event check whether it was within the range of defined polygons. If they were within those polygons events were sent to two different streams based on the polygon which they belong to.

Siddhi Query

from nospeedstream[geo:iswithin(longitude,latitude,"{'type':'Polygon','coordinates':[[[79.84941602,6.91021645],[79.85038161,6.91049338],[79.85070348,6.90979042],[79.84948039,6.90930048],[79.84941602,6.91021645]]]}")==true]

select imei , longitude,latitude,timemili

insert into filteredPoly1;

Then the entering time stamps of each individual vehicle for first polygon and the second polygon were recorded separately. And those timestamps and imei number of vehicles were passed to another stream.

from filteredPoly1#window.unique(imei) as p1 join filteredPoly2#window.unique(imei) as p2

on p1.imei == p2.imei

select p1.imei as imei, p1.timemili as timemili1,p2.timemili as timemili2

insert into joinedpolydata;

from joinedpolydata#window.firstUnique(imei) as p1

select * insert into uniquejoinedpolydata;

After that, time difference of each vehicle was calculated. If it becomes negative that indicates the vehicle is travelling to the opposite direction. From that we can separate the vehicles according to their travelling directions. Vehicles having positive time differences were sent to the ‘positivetimeDiffStream’ and negative ones were sent to the ‘negativetimeDiffStream’.

from uniquejoinedpolydata

select imei, (timemili2-timemili1) as timediffmili

insert into timeDiffStream;

from timeDiffStream[timediffmili>0]

select imei,timediffmili as postimediffmili

insert into positivetimeDiffStream;

from timeDiffStream[timediffmili<0]

select imei,(-1*timediffmili) as negtimediffmili

insert into negativetimeDiffStream;

Then the average time difference of all the vehicles belonging to that road segment within a particular time period was calculated for both directions.

from positivetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(postimediffmili) as free_flow_speed_d1

insert into avgtimediffmilistream;

from negativetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(negtimediffmili) as free_flow_speed_D2

insert into avgtimediffmilistreamneg;

Then the average vehicle speeds of each direction were calculated and the distance of road segment was divided by it to calculate the average speed of each direction.

from avgtimediffmilistream

select junc_id, ((1000/free_flow_speed_d1)*5/18) as free_flow_speed_d1

insert into avgspeedpositive;

from avgtimediffmilistreamneg

select junc_id, ((1000/free_flow_speed_D2)*5/18) as free_flow_speed_D2

insert into avgspeednegative;

This average speed data was then sent to a mysql database through a mysql output adapter in CEP [2].

From this average speed, we can define the traffic level of each direction in application level.

API

A REST API was introduced for outside apps to can call and get data from the system. The API was written using WSO2 Jaggery. It is possible to receive the following metrics through the REST API.

Get all traffic data

Sample request:

GET /apis/traffic

Sample response

Get traffic for specific junction

Sample request:

GET /apis/traffic?junc_id=kolpity

                   

junc_id : We can get traffic status in a particular junction. 

Sample Response

All traffic(only traffic info)

Sample request:

GET/apis/traffic?trafficonly=true

Sample response:

Traffic for specific junction (only traffic info)

Sample request:

GET/apis/traffic?junc_id=kolpity&trafficonly=true

Sample response

Finally, traffic condition will be visualized on a google map as in the picture shown below. Red marks are for visualizing high traffic areas and green marks are used to visualize low traffic areas. 

Introduction to configure SAML SSO in web applications with WSO2 Identity Server

SSO is the process of an application requesting for authentication credentials from an identity provider system. This type of systems will establish user identity for once and then share it across the sub systems.  

Simply saying SSO systems allow users to log in once using a single id and a password and gain access to multiple systems without having to log into them individually.

There are different protocols used in SSO services such as Keberos and Security Assertion Markup Language (SAML). Here I have discussed how to do it using SAML 2.0. SAML is in XML standards. It facilitates exchanging user authentication data across secure domains.

There are three main components in SAML based SSO services.

1. User
2. Identity provider
3. Service provider (Web application)

SSO process

1. User tries to access the web application. It is deployed in WSO2 AS.
2. Web application which acts as the service provider generates a SAML request.And there is a predefined SSO url in web application.
3. It will then redirect the browser to SSO url with the encoded SAML request.
4. Then browser will be redirected to SSO url which is going to be an instance of the identity provider created in WSO2 identity server.
5. IS will then parse the SAML request. Check whether there is an already logged in user session. If not authenticate the user by asking their usernames and passwords
6. IS will then generate the encoded SAML response which includes the username and user’s claims.
7. Then it will redirect the browser to ACS with the generated SAML response.
8. Browser will send the SAML response to ACS url. ACS url is the place where service provider receives assertions for the sent SAML requests.
9. ACS will decode the  SAML response and validate it. Then will decide whether to grant or deny access to that user.
10. User will be granted or denied access to the web application.

[WSO2 ESB] Use of Local Entries.

In this post I would like to discuss about the importance of local entries used in WSO2 ESB. Local entry is a memory registry.

Assume that you have an element which is used inside the XML configuration in a proxy service or sequence. And the value of this element needs to be changed time to time. In a case like this if you insert this in a local entry you can easily edit, delete or add values to that without changing the entire code.

Local entries are globally visible. So we can retrieve them from anywhere within the system.

There are three types of local entries in WSO2 ESB.

1. In-lined Text Entry
2. In-lined XML Entry
3. Source URL Entry

In-lined Text Entry

In here we can add any text entry. For example if we want to add a name or number which has a high probability of changing time to time, we can add it as a in-lined text entry. And then we can retrieve this value inside the XML configuration and use it.

In-lined XML Entry

In here we can add XML entries.

Source URL Entry

This is for adding URLs as local entries. If that url contains a payload to be retrieved we can get that payload simply by retrieving the value of the local entry.

Retrieving local entries within the XML configuration

We can retrieve these values by writing a XPATH function like this. Assume the name of the local entry is "localEntry".

<property name="LocalEntryValue" expression="get-property('localEntry')"/>

Assume you have a XSLT function to be executed. In a case like this we can add a xsl:stylesheet in a local entry and call it from the source code (XML configuration of sequence/proxy or API). You can even pass parameters for this xslt function.

Here I have stated an example which calls a xslt function saved in an in-lined local entry. It is saved as "test.xsl". Key of this local entry can be specified wherever a registry key is expected in the configuration.

In the following example I have stated the way of calling the local entry and pass a property as a parameter to the xslt function.

 <xslt key="test.xsl">
        <property name="date_time" value="2016-05-24"/>
</xslt>

Use of Templates in WSO2 ESB

When you have repeating code segments of ESB configurations/XMLs in your API or proxy service, you can add those code segments in a template defined in ESB. And also when you want to reuse a particular set of codes in different places you can include that part of XML configuration in a template and reuse. It will help to reduce the redundancy and your code will be more readable. A template is more similar to a class.

Basically there are two types of template patterns introduced by WSO2 ESB. They are sequence templates and endpoint templates. Here I will discuss about sequence template

A sequence template is a templated form of a sequence. Here I’m going to discuss how to call a template from a proxy service, pass parameters to template and to retrieve parameters from a template. And you can include the repeating code segments inside the template.

To create a template go to ‘Templates’ and click on ‘Add Sequence Template’. Then give a name to that.

Then click on ‘Add parameter’ to retrieve the parameters you pass when calling the template.

Here I have given two parameters (name and age). And then I will add a log mediator to log the parameter values retrieved from the template. For that you can simply click on ‘Add child’ and select the ‘Log’ mediator.

And give the properties you want to log like this.

Then click on ‘update’ then ‘Save & Close’. You can include the other relevant mediators of the XML configuration(repeating codes) here.

This is the final XML configuration of the template I created. In here we get the parameters passed from the proxy service which invokes this template and log them.

<?xml version="1.0" encoding="UTF-8"?>
<template xmlns="http://ws.apache.org/ns/synapse" name="testTemplate">
   <parameter name="name" />
   <parameter name="age" />
   <sequence>
      <log level="custom">
         <property xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns2="http://org.apache.synapse/xsd" expression="get-property('name')" name="name" />
         <property xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns2="http://org.apache.synapse/xsd" expression="get-property('age')" name="age" />
      </log>
   </sequence>
</template>

Then we will look into how to call this template from the proxy service and pass parameter

Create a custom proxy and give a name. Then click ‘Next’. Then select ‘Define Inline’. Then click on ‘Create’. After that click on ‘Add child’ then select ‘Call Template’.

There you can select the template you created in  ‘Target template’. Then you can give the values of parameters like this.

If the values of those parameters are as properties in the proxy service you can give the parameter values like this instead of directly giving the values.

Then update, save and close. And click ‘Next’ and “Finish’ to create the proxy.

Here I have added the XML configuration of the proxy service.

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="testTemplate" transports="https,http" statistics="disable" trace="disable" startOnLoad="true">
   <target>
      <inSequence>
         <property name="name" value="Sandra" scope="default" type="STRING" />
         <property name="age" value="25" scope="default" type="STRING" />
         <call-template target="testTemplate">
            <with-param xmlns:ns="http://org.apache.synapse/xsd" name="name" value="{get-property('name')}" />
            <with-param xmlns:ns="http://org.apache.synapse/xsd" name="age" value="{get-property('age')}" />
         </call-template>
      </inSequence>
   </target>
   <description />
</proxy>

Then you can run the proxy from ‘Try this Service’. Then you can see the output like this.