How we Brought Identity to the Internet of Things in Two Weeks

Mission Impossible

The Mission: Last month Lasse Andresen (our CTO) asked a small team in the CTO office to work with ARM to build a demo. The purpose was to show how ForgeRock can bring identity to the internet of things. The time available in which to build the demo? Two weeks. No really. 2 weeks. It had to be ready for IRMSummit in Dublin.

Background Intelligence: ARM are a British technology company, and are the folks behind the design of chips used in 95% of smartphones, 80% of digital cameras and 35% of all digital devices. ARM’s mbed team are on a mission to help simplify and enable pioneers and future giants who wish to build things and put them on the internet. They have mbed enabled a coffee machine as a demo platform as they build out the mbed ecosystem. It can identify the colour of Nespresso coffee capsule being used to make a cup of coffee, and sense the proximity and strength of any bluetooth beacons near to the coffee machine when the capsule is placed into the machine.

mbed_os_dppage2_diagram2-01

Figure 1: The ARM mbed os tech stack

The Details: The Coffee Machine uses an ARM mbed board to send telemetry data to an mbed server which amalgamates the data. After analysis ARM’s mbed server will publish capsule events on a web socket. Events look like this;

{
    // name of capsule currently being made
  "currentCapsule": “vivalto_lungo”,
 
    // the bluetooth tag id of the strongest signal at the 
    // or -1 if no bluetooth signal
    // was detected
  "user": 1, 
    // The bluetooth id of the machine that the capsule 
    //event occurred at.

  "machine": 0                      
}

Lasse wanted us to build a web application that would afford different views of the data depending on the ‘role’ of the user that logged into the system. The demo supported two actors;

Coffee Drinkers – carriers of ARM bluetooth tags that consume coffee from the ARM mbed enabled coffee machine.

Coffee Sellers – An owner of the ARM enabled coffee machine. Conceptually this might be the catering manager of a large hotel, or chain of hotels that could use the application to understand the coffee drinking habits of their customers and which machines provide the most value, get the most use etc.

Architecture

The architecture choice was driven very much by the timescale. It was a given that OpenIDM would be the store of identity and the mechanism by which identities (Drinkers and Sellers) and things (the bluetooth tags and the coffee machine) would be managed.

It was also a given that we would use OpenAM to authenticate users to our app. 

We needed to pick highly productive tools that would enable us to build a distributed system as quickly and simply as possible. We needed to;

  • Serve up a web app
  • Listen to the ARM web socket
  • Query OpenIDM to obtain identity information
  • Query OpenAM to validate request from browsers to ensure that the user is authenticated and authorised to access the resource they we requesting.
  • We also needed a way to persiste capsule consumption events so that we could provide the role centric data views.

We decided our server should run on the node.js platform, and serve up an AngularJS based web application. Our data would be be persisted in a restful, NoSQL, json document database as a service called Cloudant (by IBM). This would mean our application could be written entirely in javascript and all data could be passed as json, meaning we wouldn’t need to write any data conversion objects or deal with the conversion such as would be necessary using Java for example. The use of a document database meant that when our server receives an event from the ARM mbed server we can simply make a restful queries to OpenIDM to obtain json representations of the user associated with the ‘user’ bluetooth tag id and the machine that has the machine bluetooth id and put all that data into an event in our cloudant datastore.

So that would take care of the event handling – all rest and json.

What about the web app side of things? Our web app uses the the express web app framework for nodejs to serve up web pages that use the AngularJS javascript library to tie the web page’s view objects to our nodejs server (and ultimately cloudant) managed data which is accessed as, yup, you guessed it, restful json resources.

Our System

The Coffee Drinker's Story

    1. The Coffee Drinker registers as a coffee drinker with the Coffee App.
    2. User details (including bluetooth tagId) are stored in OpenIDM.
    3. The Coffee Drinker drinks a coffee!
    4. The coffee machine’s bluetooth sensor data and the data from the capsule light detectors is sent to the ARM Server.
    5. The ARM MBed Server makes sense of the data and emits simple event data containing the bluetooth ids of both the coffee machine and the nearest bluetooth tagId at the time the capsule was dropped into the coffee machine.
    6. The Forge Rock Coffee Server receives the simple event and finds the details of both the coffee drinker and coffee machine using their bluetooth ids.
    7. The FR Coffee Server persists the enhanced event into a Cloudant (NoSQL Document DB as a Service) database.

Some time later….

  1. The Coffee Drinker decides to investigate their coffee drinking habits.
  2. The Coffee Drinker chooses log in to see data.
  3. The Coffee App redirects the browser to OpenAM to authenticate.
  4. The FR Coffee Server obtains the coffee events for that user, does some really clever analysis on the data and provides the Coffee Drinker with stats relevant to them, and a timeline of coffee drinking events, that could be socialised by sharing events with friends.

The Results

ARM have built a web page of their aggregated coffee machine data on the number of capsules consumed from the coffee machine;
Screen Shot 2014-11-10 at 22.32.02

To this we added identity in order to make the data presented more personal.

The Coffee Drinker’s View

Using identity we can present individual views on the data. When a coffee drinker logs in we can show them a view of their coffee events that could be socialised or shared;

Screen Shot 2014-11-11 at 08.55.15

And we can show them statistics relating to their specific coffee drinking habits;

Screen Shot 2014-12-11 at 10.14.21

The Coffee Machine Owner’s View

The coffee owner gets an amalgamated view of all the coffee drinker’s events, aggregated by coffee machine. This allows the owner to analyse the performance of different coffee machines, experiment with promotions and machine placement and understand which capsules are being used where, and when.

Screen Shot 2014-12-15 at 10.25.16

Summary

So, in summary we built a server application that received data from ‘things’ on the internet, in this case, an mbed enabled coffee machine. The identity of both the things (coffee machine) and the people were managed by OpenIDM. Our coffee event receiver application made rest calls to OpenIDM to obtain the identity of the things and the people associated with the received data and stored events in a document database.

In order to access the data we built a web application that provided different views on the data depending on the role of the logged in user. In doing so we were able to both provide the user with specific personal data relating their interaction with the coffee machine, and protect others from gaining access to that data.

We also provided the coffee machine owner with data regarding the use of their machine and statistics explaining which capsules were popular at which time. The data could easily be socialised, used for marketing purposes, as a customer behavioural analysis tool, and as an predictive automatic capsule re-ordering system.

We did this in just two weeks, and you can too using ForgeRock’s Identity Platform.

5 Comments

Comments are closed.

  1. David G. Simmons 4 years ago

    Nicely done! And in such a short time!

  2. Katie_Gonzalez 4 years ago

    Fantastic, and agreed with David on the time crunch.
    I need something like this to monitor how often the kids open the refrigerator door….or even better to tell me when the temperature is dangerously low (such as in the case of our lengthy power outage the other night).
    Love it!

  3. David G. Simmons 4 years ago

    Back in 2005 I built an IoT device that monitored inside a fridge, and signaled light levels — finally answering the age-old question of “does the light ACTUALLY go off when you close the door?” But it just as easily monitored temperature. The problem is it was battery powered, and batteries have a fairly steep power-drop curve when cooled. :-)

    I was working on using the ForgeRock stack on an Intel Edison board I have here, but I’ve since abandoned the project.

  4. Victor Ake 4 years ago

    Excellent!
    The hue and colour that is added to the solution when identity kicks in shows how important it is in the IoT. Even when the example is for a coffee machine, it can be applied to different devices where data is more sensitive and privacy is important.

  5. Author
    Jamie Bowen 4 years ago

    Talking of fridges, my favourite IoT project to date is the brewpi. Check this out!

    http://www.brewpi.com/fridge-hacking-guide/

©2018 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?