Identity and IoT, what stakes?
Connected objects bring a whole range of new perspectives for the evolution of processes and working methods for businesses and users. Indeed, they are now able to interact with their environment to exchange information or perform actions. These interactions are characterized by relationships between corporate information systems, employees, end users and even other objects. To ensure the security of such exchanges, it is absolutely necessary to implement access control mechanisms which implies knowing and managing the identities of all connected objects of a fleet as well as their users.
This identity management discipline is well known within companies and linked to the IAM field (Identity & Access Management), that means the lifecycle management of the identities of employees and partners (traditional IAM) or end clients (Customer IAM). It must now be applied to the fleets of connected objects: it is the IAM of Things (IAMoT).
Figure 1 – Traditional IAM, Customer IAM and IAMoT: three strongly related fields
A connected object, yes… but to WHAT?
The interactions between a connected object and its environment can be grouped into 3 main categories.
1 – An object connected to the company’s IS
This is the first use case that comes to mind. Each object communicates with the IS via a unique identity that represents it and is associated to its access rights. This implies the implementation of principles for the creation, referencing, management, control and piloting of theses identities. We must know the condition of an object or the identity of its owner at any time.
In a standard technological chain such as “objects – relays – IoT platform – applications”, the IoT platform offers a central point for managing all objects identities.
In this context, it is also essential to manage the authentication of objects to applications, and therefore to define the principles of creating the secrets that will be used.
Figure 2 – Standard technological chain
2 – An object used by customers
For this type of object, appears a strong relationship with the Customer IAM field. Indeed, the object must be able to verify the user’s identity against the CIAM and determine the services to which the customer has subscribed.
In case of shared usage of the same object, a role and data model involving different types of end-users must also be considered.
Let’s take the example of a connected vehicle:
- The vehicle driver wants to use the GPS service. Before granting access to the service, the vehicle must answer many questions. What is the identity of the driver and what personal profile should I use (in order to load his previous rides for instance)? Is he the owner of the vehicle, the driver of a rental car, or has he borrowed it for a one-time use? Has the driver subscribed to the GPS services from the manufacturer and what is his level of service (routes calculation only, or also alerts for danger zones)?
3 – An object in interaction with the company’s employees and partners
Last use case, each object can interact with the company’s employees, service providers or partners. The relationship with the traditional IAM domain managing the authorizations and roles of the company’s partners and employees is therefore essential.
The use cases of an object require the creation of a role model to answer the question: which rights for which populations of users on which functionalities of the object?
Let’s take again the example of a connected vehicle:
- If repairs are needed, the mechanic must be able to view the latest vehicle’s operating indicators before the breakdown for diagnostic purposes. Is this garage part of the manufacturer’s network or independent? Is the mechanic allowed to access all GPS information or only the technical indicators of the engine? Can the customer consent or at least be informed of such access to his vehicle’s data?
This example also highlights that access rights may be closely linked to a time frame (only for the duration of the repair) or to the nature of the data (privacy protection of GPS data).
IAM of Things also means processes!
All IAM experts will agree: there is no IAM without a thorough study of the lifecycle of the identities involved. Our conviction is that IAMoT must study all the processes involving the object over its entire life cycle. Indeed, throughout the life of an object, the nature of interactions with its environment is likely to evolve according to its condition. For example, a brand-new object should be associated with its main user via a pairing process that ensures a level of trust consistent with the issues at stake…
Let’s use for the last time the example of the connected vehicle:
- A person has just acquired a second-hand connected vehicle from a private owner. In the context of this resale, it is necessary for the new purchaser to ensure that all accesses to services will be properly revoked for the previous owner. The detection of the resale event must therefore trigger a process of un-pairing the former owner.
Figure 3 – Ingredients for the IAM of Things recipe
The IAM of Things, a new discipline based on mastered concepts
This article highlights the identity management issue for the IoT and underlines the existing links with other fields of the IAM. It is important to keep in mind that even if the fundamental principles of the IAM also apply to the identity of connected objects, responses adapted to each project’s context must be carefully studied.
