A recovering academic, Preston moved from fish brains to focus on technology 20 years ago. Preston works with companies as a technologist and leader to combine electronics and Cloud technologies to bring the physical world into their IT infrastructure using Google Cloud Platform.View the profile
Zoltan Arato is a Product Manager of Google Cloud IoT, he holds a MSc of computer Science. He has years of expertise in the IoT domain and supported multiple customers in launching IoT products. Prior to Google he used to work as a Product Manager and helped to build the Xively IoT platform which was acquired by Google in March 2018. Before Xively he worked for Ericsson, where he held various roles in Hungary, US and Sweden.View the profile
About the talk
IoT solutions are complex because the data needs to proceed through different systems and layers, from ingest to application and presentation layers. This is especially true when you involve many role types, from system designers and OEMs to corporate or consumer end users. Learn how Google provides a complete set of fully managed serverless components to build such a solution by combining IoT Core for device identity and data ingest, with Firebase Authentication for user identity and Firestore for real-time application data.
My name is Zoltan Naruto. I'm a product manager of Google Cloud iot Core. Let me also introduce Preston homes head of iot solutions for Google. So he's going to be on the stage with us shortly. So today we are going to talk about the specific type of iot applications applications those involve. Of course, I with the devices. Mobile or web applications and very importantly also users and you are going to see that users will be an important component in
this presentation. And as part of this presentation video review sort of the theoretical background the business context and then we will show you a tool box using Kong Cloud iot Core and some of the Fire based products how you could Implement these use cases and we will finish with the demo. So both Preston and I have been working in around iot projects around the project for almost 5 years now and we have seen two main patterns emerging when it comes to iot use cases. The first one is I like to call them data
ingestion intensive or data ingestion heavy use cases in these use cases. There are many devices sending a lot of data Upstream. So typically the bandwidth requirement Upstream is much higher than Downstream and usually these are applications for monitoring or analytics and I mentioned that users will be an important part of our talk and ending these use cases. Usually there are less personas involved on the other hand. The other type of application be we usually see when working with customers we like to call is complex application logic use cases. So in
these uses is or applications the day tomorrow is usually more complex. There is a similar need in terms of bandwidth requirement upstream and downstream and that's because these applications are not only about receiving data from devices. But also controlling them. So most of the time this complex business logic is used to determine something's changed. It required to be performed on the devices and then send back these commands or configurations to the devices.
And what makes implementation of these use cases challenging is is the the multiple personas sort of in the mix or having to interact with these deployments. So when it comes to these complex application logic use cases, typically, these are the building blocks that we see as required for implementation. So mobile and web applications to control the devices and see directions State the devices, of course device management capabilities this meaning like credential management the grouping
updating Arab dating the firmware of the devices cloud services data management tools in the cloud or Storage Solutions or Computing Solutions user management. So most commonly and identity provider to store your user send and handle your users. We already touched upon command and control so the capability to do to interact with the devices to be able to control them and last but not least sensor data aggregation and visualization. I'm so you want to see or or Indies use case is a user's want to see sensor data or aggregated data off of
the value of one device for multiple devices and there is a horizontal layer here. So all these building blocks are used by various users when personas and and these users have may have very different Access Control needs or limitation and this is going to be your focus in our talk how to implement authorization for this users because we have seen that many times. This is very challenging. So depending on how the business is run the same building blocks are used and there are three main categories here. We are going to see examples for
each to be to be a business-to-business B2B to be there is another be added here and the to be to see and the first be is is always the coyote or or cloud service provider. So in our case is Google Cloud and then the second be is our customer and in many times our customers operate a service center of fast service and iot solution using our infrastructure and sell the services either to businesses or or consumers. so to give you an example of all of these probably the B2B scenario is the is the simplest in terms of people
implementation and probably the best example would be a connected Factory or connected manufacturing line so so effectively with connected plc's when it comes to implementing these use cases based on these business models usually it's enough to use the resources provided by by the the cloud service providers Owen K in this case Google Cloud so these are existing resources or building blocks and and implementing these use cases can rely only on these people are components and very importantly
there are Hindi to be useless This is a little bit more complicated to be to be to be a scenario may be the best way to describe the discovery of use case. It is true an example. So imagine a connected truck Fleet Management System a company that provides this truck Fleet Management Services as access service and they also had said they also sell Hardware that their customers can install in their trucks for can the other vehicle as well and they're our end users in this in this scenario. So
if you think about the customers of this s provider Saudi connected truck Fleet Management System provider, those users are end-user so for instance a driver or or operator I forgive and sleep and we have to realize that in these use cases. There is a really wide spectrum of roles and permissions. So just to reflect on my my previous example a driver has a really different access rights compared to the manager of a horse. 2B 2B 2C scenario is a little bit simpler, but similar to the
previous one, probably this is the most familiar to all of you a good example would be a smart lighting solution. Really. The only difference here is that the end-user are consumers and and Indies use cases there are multiple personas and Andros information requirements, but typically less than in case of B2B to be I wanted to show you a real world example and it's very relevant here in San Francisco. So you might have seen the scooters out on the streets. These
are connected scooters. So they are connected to the internet and there is a corresponding app where there's an app that you need to use if you want to if you want to ride the scooters and There is a very complex business logic behind the disservice. So if you think about it, the user of the application and the scooter needs to gain access tried to the to the scooter just for the. Of that person is riding the scooter. So there this the pretty complex business logic here and and
and they are actually using Google cloud services. Just to give you a summary of these various business models or sort of overview done. So in all cases the the manufacturer is it some kind of device maker or an oan that's that's common in in in all three scenarios. When it comes to the owner of of the devices, so who owns the device in case of B2B, this is Trivial. It's it's the it's the current customer of the cloud service provider. So it's a corporate owner or operator and there is no end user in case of be to be in the other
two categories users in case of B2B to be the interesting thing is that the owner is also corporate owner and owner operator, but the end-user is different so they don't necessarily only Hardware. So just to reflect back on the truck Fleet Management System. This disorder or disease tracking devices might be installed on trucks. But but that's a the driver of the truck doesn't necessarily on the device. In case of B2B to see this is a little bit simpler because in these use cases usually the owner and the end-user are the same person. So think about the connect
light example. All right, so when it comes to the implementation and then we will go into the actual details very soon. But just to review that there are two main layers of the sort of beckoned implementation of these use cases application and infrastructure just like another other systems. This is true in iot as well. So what's typical for infrastructure is that usually there or cloud services and these are pre-existing building blocks. So for instance like a
computer engine instances or or devices, but there are many of them in Google Cloud. What's common is that there is a service for cloud. I am and Cloud. I am controls that what sort of permission is given user has on. What resources and in this layer the the resources are obviously defined by the cloud service provider? So in our case is defined by Google typically form in case of B2B use cases. The implementation is heavier on this layer in this layer. So there is less need for for an application layer because you can usually use this PX distinct building blocks.
The application layer. This is where the business logic most of the business logic is implemented. This is where the command-and-control decisions are made. And and this is the layer responsible for for transmitting these decisions to the infrastructure layer digital version of of the business model of forgiving use case and this layer is usually thicker in case of the B2B to B&B to be to see he was cases. Now an interesting question is that of course these two layers live together. So they are implemented together and and and
both exist and there's always some sort of overlap between the two and the question is how do we cross over between the two layers? How do we bridge between a device that only exists as an infrastructure piece? And it's authorization is controlled by I am so how how do we provide access to this device for user that for instance only exist in a third-party identity provider which is which candy axe even external to Google. And the good news is that Google has solutions to solve these problems
and we have tools to implement diesel to recession control mechanisms. And so I would like to invite Preston on stage to tell more how to do that. anchor Zoltan So we talked about the general cases of the infrastructure layer and the application layer. So if we look first at some of the infrastructure on ways that we can apply I am in iot Cloud iot Core, which is our primary service for authorizing and identifying and securely connecting devices that exist out in the insert of the
field to the service has a set of IAM permissions and roles that let you define who can do what with the logical device resources that are stored in iot core and like many Cloud. I am permissions. These can be applied at different scopes of influence. So this is an example of where these permissions can be applied to the entire project. But inside Cloud iot Core, we also provide the ability to apply these permissions are rules to specific device Registries are collections within a project. So this is something where you're applying clad. I am to
control who can access for who can perform certain actions on cloud resources to find by Google in a managed service like Cloud iot Core. The other thing you can use I am for his is controlling access to who can publish to certain Cloud pubsub topic. So Cloud iot Core and Cloud pubsub a very tightly integrated and by limiting who can publish to certain topics, you can constrain Pub sub that they're only only messages being published by devices to iot core arrive on a pub sub topic in this is important because that way you
can use certain attributes published by iot core on messages such as a device ID. And I know that those attributes were only I'm coming through devices and not through some other Cloud publisher online that has access to that Pub sub topic. So it's one of the constraints you can put I'm on other systems at I-44 interacts with No the Apollo to talk with Archie and fire bass and Firebase is actually a very large Fleet of of products and services on the North Shore Li not going to cover the mall today. There's also the fact that has a number of these Services Now sort
of have dual representations in both. There's a Firebase experience and the cloud gcp experience. So the ones were going to be touching on our authentication hosting fire store in Cloud functions. So authentication is the kind of customer identity management. I'll get into that a sec hosting a static hosting firestore is a document database and then Cloud functions again. This is the same back into four structures shared between Google Cloud platform and fire bassist far is executing lightweight functions. So the first is around identity management.
So when do time we talked about the main components? This is how you manage your own user. So when you do have end-users involved, you need a way of managing who they are that handles user authentication recognizing that these users exist in your system. So when a developer logs into Google Cloud platform power of Google identity system is what we expect infrastructure users to be able to log into now you can you can integrate that with a d etcetera but that's identity management for infrastructure. This is identity management that we offer as a service for you to incorporate
into your own applications. And once you have authentication then to address authorization, this is where Firebase rules that apply to firestore come in and this is a service that allows on applications to communicate directly to the database without Waiting to go through any sort of API middle tier and if you're going to have applications talking directly to a database you need to apply authorization logic. I'm in the way we do that if we allow we have a service that basically lets you describe that authorization syntax in your
application and have the database actually apply that for you. So we'll get a little bit more and some of the Syntax for these rules a little later. But let's talk about the kind of architecture. We're going to show and and demonstrate here and that is we've got some devices on the left. These are kind of hypothetical sort of gas sensors. In this case. We're going to use and then users end-users interacting with an application on the right. So the first thing we do is we're going to use Cloud iot Core to securely connect devices to the cloud and then on the application side, we're going
to host the static content related to the application and and deliver that to users in a in web browser for mobile applications from Firebase hosting and then the live data that the applications going to be interacting with his going to come from fire store. But because fire store is directly connected application, we're going to make sure that firestore rules are applied to the way the application is getting data in and out of fire store now to connect these two for device sensor data, we're going to you Speak louder i g chords integration with Pub sub and then Cloud
functions that takes readings from centers and write them into fire store. We also could have chosen other Cloud platform database products to do this. For example, we could write this Center series did in the cloud bigtable very scalable way of doing series data to be honest. And then this case it would have ultimate we would have had to replace the fire store rules with our own authorization implementation. So we're going to go with the simple path here in just use fire store because he gives us that rules True Value. We're also going to send information from the device in
the fire store about the current settings and state of the device. So this isn't necessarily the sensor data, but this might be other I'm current settings and values that are on the device changing less often and then finally when a user changes of setting in a device, we need to get that back out to the device again, we use a Cloud firestore trigger to run a cloud function when they the changes in fire store in that cloud function than can send the updated configuration through iot core to the device. So when you put it all together, it looks
a little something like this. So what we're really trying to leverage here is using as many service and managed Services. We've got Direction data flowing in both directions and then we've got static content and data being serve to an end user application. So the the scenario for the demos going to be sort of a hypothetical technician who needs to check out a piece of equipment and here is my gas sensor that we're going to use and what they're going to end up doing is connect to it through a mobile app.
So this is I'm going to test the demagogues because I've got iot device a tablet and a demo laptop all concurrently interacting with the Wi-Fi saturated world, so this so if we can have the demo system up. Got it. All right. So let's start with the we cannot go ahead and I'm going to restart the the casting here. if we can have the looks that has the Henry connect baby guys, love Dara requirements list for this one. Alright, so here's the tablet. I'm going to launch
this app. So the first thing is to go ahead and back out of me to log out to this app really doesn't do anything until you login. So when I login with Google, that's actually maybe I'll just keep it that way. Honestly when I login with Google, I've already authorized this app. So directly is going to go to a list of devices that are associated with me. This is a new device are just kind of check this out of Iraq say a shared rocket the technician and what's displayed on here is a code that says let me as an employee claim this device that I have sort of exclusive control over it. So if I
add this claim ID. And it's my favorite ones. I'm just going to name it save. Most of you won't be able to see the change but I was hit claim and as long as the network is still getting connected here just now says claims so the device is now recognize that it's claimed. I'm going to go into the detail view here. So when you see on that real time live graph is is light data light sensor data coming from this device and that's coming through that Telemetry path
that I showed in the architecture. You're also can see that there are set of them configuration settings and that is a tilt threshold. And so what that means is I have an angle set that if I tilt this device past a certain range, I got a Beat Not at the user if I want to change the tolerance of those tilt settings, I can go ahead and Indus app and an are those down. Let me just text me narrow one side here when I hit update. You see the little spinner open the dialog. That's actually letting me know that it's taken a moment for the settings to get to the device and then the
device. Do not again, huh? What what you can see here is I've narrowed the Tilt setting now. It's a lot more sensitive. Right? We'll go one more time. We have enough time that I can you bear with me will This is a relatively older tablet that I pulled out for this particular thing. So I think between us and the stage. So before it glitches again, I'll do this one more time. I'll change it setting update it. In fact, I'll do it again when we come out. I'll narrow this
other direction of tilt. Hopefully I can put it into a state of here. We'll see here that now if I tilt this essentially what I'm tilting but what I want to do is show you back on the laptop. A little bit about what's going on here. So that's progress spinner is actually giving the user of the tablet and indication that the setting have not yet actually been verified as received by the device. So I change the setting in the UI. I update the setting that changes data in Cloud firestore not change of data in Cloud firestore triggers a cloud function to run
and send the new settings down to the device through iot core. When the device receives the settings that applies them to the Tilt sensor, it said send another state update message back through that other top pathway which confirms the state as updated in fire store in only when do those two data values reconcile does the spinner go away. So when you saw me update the setting in the tablet and the you saw spinner for a moment that's actually a sort of a full round trip to the device and back confirming those settings.
I'm going to show you a little bit more about how these Firebase rules apply because these rules are what are preventing one user from seeing data from device for changing setting of a settings of a device while another user has that device claimed. And the syntax of these rules is based around matching patterns of a document in firestore. So first of all of the outcome of a rule is to allow or not allow a given device. So essentially it's deny by default and
unless I'm matching rule is found don't allow the user to actually read or write data from the database so you can see the the operations can be read or write. There's actually also update and delete And the main one I'm going to point out is the kind of middle section here. So I'll go from the top which is that the first rule is around letting a user basically update their own user's profile writing that makes sense. Unless the user the requests coming from the user matches. The profile users ID. You
can't update somebody else's profile. The second one is related to the device record itself. So in this case, we want to allow a person to create a new record if they're going to be the first to claim a device that can have that entered. They also can read and write the settings for a given device cuz that's where the updating of settings is being written to And then the Telemetry pass this is where we're storing incoming sensor. So that real time line graph was going to a Telemetry collection just the back up and give a little bit more contacts for those who
don't know too much on the on the fire store front of the document database documents are organized into collections. So here were talking about three different collections users devices and Telemetry and the way firestore rules are applied. If you can apply them only two documents and collections that match certain patterns in the case of the middle one hear. What we're doing is we're taking the device ID, which is also in this case the document ID and using that as a variable in the rule,
And just to show you. The way this works from the at the actual data base layer. I have another user logged in to the same system. And since the URL path was used for getting the data from that device. If I try to put in that device URL, you'll see that not only is it being blocked at the web front-end logic? But if you look at the developer console to the permission error is actually coming from the database, right? So if I didn't show you this developer console Indie, very easy to sort of say. Oh, well, this is authorization logic happening in the
application in the front end that is subject to bugs and are in the way authorization is applied. So here by seeing the developer console. I can show you that this is actually being enforced at the Firebase client library and back and integration point if I go ahead and we don't need to put the tablet up, but I will go ahead and and release this device. from this user and if I go back I can now claim this. And now I can see it and now I can actually get to that URL for the detail view. So that's how we really use for the real time nature Firebase
firestore to basically apply these rules based on the data. That's in the database. I think that's the other key takeaway for firestore rules is that they are applied per request / document in a way that lets your own rules and your own data models in the database be that custom application layer of authorization. So while I am has a focus on the resources or the models that are defined by Google if your defining the to sort of application object in first
Buy this talk
Access to all the recordings of the event
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.