Blog

<p>Within the wot.io data service exchange (DSE), we often need to interface different web APIs to each other. It is not uncommon for 3rd party software to have limited support for secure connections. While we provide SSL termination at our secure proxy layer, there are many legacy applications which can only communicate via HTTP. You can envision the problem space are follows:</p>
<p><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/relay.png" alt="relay matrix" /></p>
<p>In order to address this connectivity space, we developed a HTTP/HTTPS relay that allows us to receive both types of requests and translate their security context. A request can be received via HTTP or HTTPS and be sent out via HTTP or HTTPS independent of the original request. By adding a simple rewrite rule to our proxy layer, we can specify the desired translation. This makes it easy for our developers to integrate software that lacks support for a security scheme to integrate with one that does.</p>
<p><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/relayarch-1.png" alt="base architecture" /></p>
<p>Another interesting side effect of the relay is that we can use it to transparently proxy both request and response data to the wot.io data service exchange. Both the request data and the response data are made available on the exchange as resources. We can then integrate those data streams into any of the integrated data services.</p>
<p><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/wotarch.png" alt="wot architecture" /></p>
<p>With the wot relay, we could log all of the requests to a 3rd party web api made through the relay to a search engine like <a href="https://www.elastic.co">Elasticsearch</a>, so that we can later study changes in usage by geography. At the same time, we could store the raw requests into a database like <a href="https://www.mongodb.org">Mongodb</a> for audit purposes, and use a data explorer like <a href="http://www.metabase.com">Metabase</a> to create custom dashboards. We could also log the same data to a monitoring and analytics provider like <a href="http://www.circonus.com">Circonus</a> and monitor the reliability of the 3rd party servers.</p>
<p>From the viewpoint of the HTTP client, the backend service be it http or https is available through the corresponding wot relay address. The developer of that application need not worry about changes in requirements for data retention, metering, monitoring, or analytics. The only change is that instead of calling the desired service directly, they would call it through a <em>relay.wot.io</em> or <em>secure.relay.wot.io</em> address. The only difference between the two addresses is that the <em>secure.relay.wot.io</em> only works with HTTPS servers, and will not relay to a HTTP server.</p>
<p>From a security standpoint, the client may connect to both the secure and insecure relay addresses through HTTP or HTTPS. In the case of TLS connects, we guarantee that we will validate the upstream certificates, and will refuse to relay the request should we not be able to verify the x509 certs of the upstream server. In this fashion, your application need only be able to verify the signature of the wot relay service itself, and not worry about validating the signatures of all of the potential upstream services you might wish to interrogate. In this way we preserve the chain of trust, and do not engage in any man-in-the-middle TLS tricks.</p>
<p>Having this layer of indirection, most importantly, opens up the full data set to inspection. Since each request and each response is forwarded to the wot data bus, any number of data services can be used to process both the requests and responses. This allows the application to be extended in new ways without having to rewrite the integration. The relay makes it easy to generate new valuable data streams and insights from your application behavior at the cost of a few milliseconds in additional request latency. As the wot data bus allows for filtering data both based on meta-data and content, it also allows you to expose the data in highly selective fashion to your customers, internal clients, and legal authorities.</p>
<p><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/wotarchextended.png" alt="wot extended architecture" /></p>
<p>Using the wot protocol adapters, we can also expose this data in real time to a wide variety of protocols: HTTP, WebSockets, TCP, UDP, MQTT, CoAP, XMPP, and AMQP. These protocol adapters provide a protocol specific interpretation of the wot data bus resources, complete with authentication and complex authorization rules. For example, you could subscribe to a wot data bus resource as an MQTT topic, or observe it as a CoAP resource. These protocol adapters also support bi-directional communication, allowing a developer to inject their own data back into the wot data bus as a sequence of data grams or as a stream of data. The flexibility of this system allows for easy cross communication between many different types of applications in different contexts.</p>