Peter Groeneveld - Implementing Consumer IDaaS for Your Smart Thermostat

Yeah, no good morning everybody. So my name is Pedro Feld. I work for cap Gemini working years, and we're going to talk about the use case, an actual customer of ours cm. I make it a little bit different. Also throw in some, some the IOT stuff, but with her go into that, there two things that happened the last three weeks that make me make me think there's any relation to consumer identity today.

And, and one of the things was new corporate identity. So this is what it was. And this is what it currently is for trying to show you that here. And the reason behind it, as I was told my day, swipe that through the company in one big bang on one day on all offices, cetera is because of the way we want to be perceived by our customers that make me think, oh, that's best deal.

So one of the things that we've go consumer identity and access management, how is the consumer looking at us and how can I deliver the most seamless user experience to the customer that makes it appeal to me as a brand to become, or a customer. One of the other things that was actually last week, that visited story was exhibition in interest together with my son. I didn't move too much into it. Front.

I came into the exhibition and the first thing I saw was it's all about identities keeps coming back to me somehow, but it had a whole buildup on how people's identities are formed by family, by education, where you grow up, cetera, cetera, and how you become all different and why eventually we end up all having a smartphone and probably if we take all the smartphone here in the room, lay them together, and none of them will be the same. Everybody's customized its its phone. And everybody also wants a customized user experience more and more and more. We interact with companies.

So that's, we get the actual use case. So we're going have a look at TV and it's more thermostat where we started, but end of last year, beginning of this year, combined identity life cycle, and perhaps keeping up with the different technical standards. And what is, what is QB? QB is a company in the, in the Netherlands in Amsterdam. So it started like 15 years ago in home automation. And in 2012, they were bold by white electricity company in, in the Netherlands Inco because they have made this nice thermostat and it's called tone in the Netherlands.

It's also being sold in Belgium it's and basically it's, it's got a very nice user interface. That's all kinds of different functionalities.

It's, it's flexible, what it can do. It's they're, they're running more and more functionality on the device. It's that's one in your home. Obviously it has an app connected to it. Why you want control that from your, that it's not a good idea to create this picture for it. With QB changed its vision from just being a smart thermostat, because there are only that many customers in the Netherlands that are customer of ANCO or electricity company in Belgium, you want grow as a company, they've got huge ideas and where they want to go.

And at the moment that sometimes go, it was just a smart thermostat. Where do we coming from? They made it not much inspection with external developers and they wanted to open up the platform that I have. And the problem was that's where we started. Didn't have a nonelectric architecture on it. It was built per customer and actually which they call tenants. So every electricity company that sells the devices is called a tenant and they build an infrastructure per tenant and all the devices are connected to it. Through the VPNs.

It's very, very hard to scale and they had this ID on where they wanted to go and they wanted to open up the, the device and the development of functionality on the device to remove developers run much more functionality on it. They actually they've implemented connections to, for instance, you can connect your, your solar panels to it. It's got boiler module that you can connect to the boiler. You can connect Phillips Ulighting to, to the device. And they needed a far greater scalable infrastructure underneath also to open up to external developer.

So to create an open platform, which not just QD as a company can develop functionality, but also create a possibility for external developers to, to create functionality and integrate it into the platform. And that point to build a whole smart up interface for the home and a commercial ambition. Cause as I said, it was not just, there are only that many customers in the Netherlands and Belgium, and if you really want to grow and sell some things and you have to, you have to expand and get other, get other electricity companies to adopt the device.

And that's what they're gonna do in the EU and the United States. And one of the first new customers that I have is in Spain. And eventually they hope to grow the whole platform, millions of devices and consumers attached to it, which makes it a very interesting source of information, obviously. So where did we start?

As I said, we started at the infrastructure that they created from scratch. So we start building this thing. Main focus is on the device itself and the infrastructure itself really needed to be improved was some identity information in the platform was scattered. So the devices were connected to the platform through VPN connections, device identities were stored in Azure ad customer information.

That's very interesting one in this case because the customers here were, we have the identity are actually not owned by cuing because they're a customer of the electricity companies and the users of the device don't know cuing. One of the tenants actually used a customer authentication through the university company's backend services to Okta and the other company used a QB data store. So the identity data was stored in the local database at QB itself cause they didn't have a federated external identity store.

The way the applications on the mobile phones connected to the backend was different. Have already grown for the second to watch. So what authentication two different platforms. So if you start connecting a third one, build a third platform next to it, maybe do it a little bit better again, and then you have three platforms to manage. So that was not going to work for long run. If you really want expand to a lot of devices and a lot of tenants that you should. And so we came up eventually with, with this picture. So we're three horizontal layers. We all be implemented on the cloud.

So device to cloud connectivity at the top, which take takes care of getting all information to the device, getting all the commands to the device and getting all information from the device, API management layer for running the services, the functionality from all the smartphone apps that are connected, but also to connect in the back end, the different customers of QE D tenants. And then there's the fourth layer in which I was involved that's identity and access management.

And that add some very specific requirements, obviously because all three other components are completely relying on the, on the identity nexus management component, all identities of the different identities that are in the network acting together are there, but no, no identity information is actually completely stored, will be stored in the QB identity and access management layer because some of it will be federated federated because the customers of the electricity company are the customers of the electricity company, such data is shared with that company and not with Cub.

So there are some, some nice challenges in this, in this environment. It has to be scalable. As I said, a couple of million of devices and it has to keep up with the whole infrastructure has to keep up that.

As I said, there are a lot of different identities in this network that we can actually distinguish. And that poses a challenge because of the different life cycles that we have to take into account before Martin John talked about the difference between enterprise identity and access management and consumer identity and access management in the enterprise.

It's, it's quite easy. So people come in HR go through different change cycles and eventually they are off board. That's in controlled world. If you start thinking about consumers, are they on board? You don't know where they work. You're coming from collect data. You don't know when they go away or something doesn't run up anymore. And then there's the extra complexity of the, of the device itself as an independent identity on the network. So you ship it out of the factory. And then at that moment it disappears. It goes into a box and eventually ends up, wakes up at somebody's home.

And then you have to try to establish, okay, where is it? What is it?

What, what is it going to do on who, on whose behalf is this device actually going to act? So this is a picture for a couple of years now, and this Life cycle in this evolution picture, we actually have all the identities in place that we see in the Cuban network. So there already employees, employees, and partners, consumers things, and eventually the relationships between those things and everything makes it more and more complex, more complex to create user experience, more complex, to skill.

What are, what were the elements that we have to work with? So on the MP side, there's Q QB employees who are on the network. We allowed to do stuff with the network to support eventually their customers, the tenant and those employees. They support eventually the customers. If you bring everything together in one cloud based Ida solution, you have to keep those tenants support because the identities, the end majors are actually launch by the tenants and we don't want support employees of tenant. Number one, to be able to access data tenant.

Number two, then in the environment of the smart thermostats themselves were also a couple of very interesting computations that impacted the usual life cycle, the life cycle. So there's the element of the contract owner, the contract owner, who has the relationship with the tenant, which, who is not necessarily the end user, because he could be branding out his home or it could also be, for instance, the contract owner of the electricity is actually owning a large apartment building. And the end user G end users are in the, are in the different departments, end users per device.

There's average of 2.6 estimated users per device. And that's basically a family. So of my help, it's me, my wife, my son. And also there, you have to worry about, okay, how do we actually arrange authorizations within that group of users? Because what I don't want is my 16 year old, some sitting upstairs in his room laying with the feet of geo lightning downstairs in the living room, doing the lights on and off on and off. So I would rather like to somehow limit what he can do on his app, to his, to his own, use The devices, multiple devices for home with also multiple devices per hour.

I can have a device at home. It also, if I have vacation college where I have electricity contract of a different electricity provider, I can have the same device hanging over there. And I very much like to install just one version of that and be able to control both devices from there. There's different services in the network, especially when there are tenant bound that made or made not to certain actions or identity information.

And there's external developers that we want to also encourage and that we want to provide with the best experience possible to start making nice functionalities for that we can actually run onto device. So that was the whole background for the life cycle. And you go back to this, this one all the way up is the relationship. How do you create that relationship between all those, all those identities where we started off with was especially the relationship between the user, the tenant and the device. How do we create that? We built that.

So coming back to this picture, we started filling it in other streams selected, selected, there, there cloud platforms for the, for the different components, API G for the, the API management layer on web services, web services, microservices layer, Microsoft Azure for the connection of the devices, to the cloud platform and for the identity and access management layer selected intervention to, to build that on the, a welcome high gas solution and Requirements. Couple of them we've already mentioned sustainability. One of the most important ones that we found was it needed.

We, we would be able to create it quickly. So very short, lean time from selection. So actually having something running and working with it, but still having the flexibility to work together, to build some specific elements that we had in this specific use case and supporting all the different life cycles.

Mm so, and there are, in my opinion, in few different ways that you can, I, that there's either complete standard products. You buy them, they are SD, take it or leave it. You can do full, full, flexible Ida solution based on the standard stack, then deliver it either from private cloud public cloud or in hybrid construction, anywhere you like it or something in the middle. And that's what we found the most appropriate for this implementation. Quick implementation standardized, but still a lot of, a lot of flexibility that we can to do this platform.

So after the selection we started, we started building designing, well, don't go into the details. We started drawing a lot of these things. We also found support for the over device flow, which we needed to actually make the registration between the users, the tenants and the devices work was quite complex.

And we, a lot of health work on that to create this. Don't try to explain what's going on here at, to end user. That definitely doesn't work for user experience. I try then I was sitting at home making actually this picture about setting up that, that triangle. And I was sitting at home on the couch. My wife was sitting next to me and she thought, well, like show some interest in what he's doing. What are you doing? And I tried to explain what's going on here. So you go from the end user and you click on the app on your mobile phone.

And, and well, let's say you push temperature up a little bit. So the device, so the app first needs to check goes, goes to Apogen. Apogen needs to check with our welcome. If the app is actually allowed to do this functionality. So it goes to, goes back to refugee, goes to Azure, tried to explain to my wife where all these things are, are running. One story. Eventually the conclusion of my wife was, well, I'll just walk to the thermostat and click was one on it.

And yeah, she thought it completely ridiculous that this was all going on under the hood, just to get the temperature a little bit. One of the things worked very well in designing all these, all these flows was the connection with, especially the guys from QB that built the, the thermostats themselves, because they have to build it into the thermostat and they're into stuff, creating nice software that runs on the device, but actually OWA open ID connect flows. That's completely to them in the beginning and this made it very visible.

Okay, let's go into the details of every little flow. Why is it done? How is it done? What are the actual calls underneath? And to build up knowledge at the client on how they have to create this and eventually ended up with a complete working flow. And at the moment, the whole platform is, is delivered, ready for the first standard to, to support production. So one last thing, the standards themself also don't help very much because they're very much in development. That's not only actually with this year space, we're currently working also for two financial institutions.

We see the same O IDC is all driving stuff behind things like PSD two and the financial sector, and also their customers are struggling because the standards and the standards that are built up in top of standards, like our connect development, also, the open banking standards is, is still very, very much in development and a lot of functionality being delivered. So that, that also takes a lot of time to keep track on what's going on in the market. Only in the different areas, keep in mind, it is constantly changing.

And the problem you're facing today might be resolved with standards development tomorrow. So as I said, wrap up, so current situation is it's on the identity and access management side. The whole platform is ready to go currently waiting for the first customer to be onboarded on it. Any questions with these other.