The Web is built on HTTP, a protocol designed for interaction between web servers and traditional PC and mobile clients (and increasingly secured by default with SSL and X.509 certificates). While HTTP has long enabled connectivity, the Internet of Things (IoT) stretches the limits of HTTP's capabilities. The "Things" of the IoT are often constrained or limited in some way - either in processing power, memory, battery, connectivity or cost - to fully implement an HTTPS capability. To overcome these constraints, these devices typically communicate using one of a number of alternative protocols like CoAP, XMPP and MQTT that are designed to better deal with these constraints.
Over the last decade, a set of standardized identity protocols which presume HTTPS capabilities (e.g. SAML 2.0, OAuth 2.0, OpenID Connect 1.0) have been defined and widely implemented for client/server communications between applications and services. These protocols can provide HTTP-based applications with a consistent, secure and privacy-enabling authentication and authorization layer which is critical for a scalable and secure Web.
The work of defining a comparable authentication and authorization layer for the constrained-device alternatives to HTTPS is underway. As an example, the Authentication and Authorization for Constrained Environments (ACE) working group in the IETF is defining how to apply the OAuth 2.0 model of delegated authorization to the constrained device CoAP standard. The ACE effort is encouraging but much work remains and it will be sometime before a) the effort is duplicated across other key constrained device protocols and 2) support for these authentication and authorization mechanisms appears off-the-shelf in actual devices and software development kits.
Ping ran up against this situation in a recent customer deployment. Ping's customer needed to enable authentication and authorization for devices sold and deployed to their customer's factory floors. The data from those devices (ink supply levels as an example) needed to be collected, delivered to a cloud IoT platform for analysis in order to determine if any immediate actions needed to be performed (e.g. ship more ink when supply runs low), as well as fed into further analytics systems (e.g. aggregate usage metrics across products). The customer wanted to leverage the IoT platform's support for using OAuth tokens as the authentication mechanism on the API calls to the cloud. As Ping has an OAuth Authorization Server (AS) in PingFederate that can issue tokens to API clients, the architecture seemed straightforward. The deployed devices would request access tokens of Ping's AS and then attach those tokens on its API calls to the IoT platform in order to authenticate those calls.
But there's the rub--the devices in question did not speak HTTP (much less HTTPS), but rather only MQTT. The Message Queuing Telemetry Transport is an OASIS standard that is optimized to support messaging transport from remote locations or devices involving small code footprints (e.g., 8-bit, 256KB ram controllers), low power, low bandwidth, high-cost connections, high latency and variable availability.
The challenge, then, was how to apply the OAuth model (which by default presumes HTTPS) to these MQTT-enabled devices.
To help us address this challenge, Ping partnered with Flowthings.io and leveraged the IoT edge orchestration capabilities of their platform. With Flowthings's agent deployed at the MQTT broker, we were able to bridge between the MQTT-world of the devices, the HTTP-world of PingFederate and the IoT platform APIs.
The flowthings.io solution consists of an "Edge" component, which, as the name suggests, is deployed to the edge, close to the devices, as well as a "Central" component that can live in the cloud or as a fully-managed private service. The central component orchestrates interactions between edge components and provides real-time data aggregation, routing and dissemination services along with a host of developer-focused capabilities.
The edge component can run on any device that supports Java 8 and has approximately 70MB of RAM, which is common for low powered gateways that aggregate command, control and data acquisition activities of one or more "things". In our use case we deployed an edge component next to the existing MQTT gateway along with an instance of PingFederate.
In a matter of minutes, using the visual tools (pictured below) hosted on flowthings.io central, we created a workflow that reads incoming MQTT events and translates them to authenticated HTTPS requests. It leverages PingFederate for issuance of OAuth access tokens and optimizes with an optional in-memory cache. From flowthings.io central we can deploy, modify, and monitor this workflow running on one or many edge components at any number of customer locations.
Take a look at the following diagram for the architecture
The solution leverages the Flowthings platform to push orchestration logic out to the edge near the devices - in this case the logic of how and when to interact with PingFederate's AS in order to obtain OAuth tokens to use on subsequent API calls to the IoT platform. The following screenshot shows the Flowthings policy UI by which the orchestration rules are defined:
The Flowthings edge component effectively proxies the OAuth token request to PingFederate on behalf of the MQTT device. PingFederate is able to lookup the identity of the MQTT device and perform an authorization check before issuing a token. In this way we are able to inject tokens into the process of mapping from the MQTT message to an HTTPS API call.
Ping and Flowthings expect this model of bridging authentication between constrained devices and cloud APIs to have broad applicability in the IoT and plan to continue refining the integration. We're looking forward to exploring the ways in which this model can enhance authentication in IoT initiatives and so advance its adoption.