The ForgeRock Identity Platform can securely manage millions of digital identities for your comany. We often think of an identity as a representation of an individual—a person. In a traditional enterprise, an identity is usually assigned to an application or web service user. In an IoT ecosystem, identity management is just as important for devices as it is for users.

Here is common example. A consumer establishes an account with a company that provides internet services. The consumer purchases audio speakers for each room in the household. Then the consumer connects the audio speakers to the internet. Now each household member can stream audio services for music, television, and other home entertainment. Does this seem familiar? The consumer has just set up a household IoT ecosystem.

In this example, each member of the household has an identity, and each audio speaker has an identity. The parents in the household can stream audio unconditionally in every room in the home. But the parents configure the internet service to allow their children to use the audio speakers only under specified conditions. For example, the parents can allow or deny a child access to streaming audio content based upon the time of day, or based upon the room in which the audio speakers are located. Each audio speaker must have a unique identifier, and each audio speaker must be must be associated with each member of the household.

In the business world, the relationships among service users and internet devices are more complex. But the concepts of customer identity and access management (CIAM) are the same. In the ForgeRock Identity Platform, a user is represented by a unique username. The user's e-mail and phone number are stored in the Directory Service as user attributes. Similarly, an internet device can be represented by a unique serial number. Device details such as media access control (MAC) address and physical location address can be stored as device attributes. In this way, you can think of users and devices as peer objects in the data repository.

ForgeRock’s identity-centric approach secures the relationships between service providers and users, between users and devices, and between devices and other devices. This lets you build new, secure, personalized user experiences for your customers. ForgeRock Identity Platform provides the building blocks you need to get started with IoT:

Together, the use cases in this guide tell the story of a typical smart device life cycle. In each of the following use cases, the smart device is an audio speaker that can access streaming audio services for music, television, and other home entertainment. Embedded software and its ability to connect to the internet over HTTPS make this a smart speaker. The smart speaker has no graphical user interface of its own. But an end user can use a secondary computing device, such as a mobile phone or laptop computer, during setup and configuration.

ForgeRock Identity Platform links the end user's identity to the device identity, personalizing the device. Once the end user personalizes the smart speaker, the smart speaker can connect to its manufacturer cloud service of behalf of the end user. For example, the end user can push the smart speaker ON button to begin streaming music —without having to access a website or other user interface.

The end-user interactions in these use cases could all take place within one user session. It's likely that the end user would set up the smart speaker and be listening to streaming music within 15 minutes. But ForgeRock's role begins well before the end user purchases the device. Identity management starts when the smart speaker is being manufactured.

In this use case, the smart speaker manufacturer creates a unique identity for each smart speaker on the assembly line. Factory workers stamp each smart speaker with a unique serial number. System administrators use ForgeRock Identity Manager to create a device profile for each smart speaker, and to assign each smart speaker a unique media access control (MAC) address. The device profile data is stored in ForgeRock Directory Server.

Additionally, each smart speaker is equipped with "call home" software before it leaves the factory. This software lets the smart speaker contact the manufacturer cloud service directly—without a user interface—over HTTPS. The following figure illustrates the communication flow among ForgeRock Identity Platform components and the manufacturer.

Figure 2.1. Creating and Storing a Device Identity

You can use IDM to create device profiles and to provision an identity data store. For more information about provisioning, see the following topics in the Identity Management product documentation:

You can use DS to store and index device profiles. DS scales to millions of users and devices. For more information about directory data and storage, see the following topics in the Directory Services product documentation:

In this use case, after purchasing the smart speaker, the end user uses a laptop computer to access the smart speaker manufacturer website. The end user enters information such as username and email address, establishing a user identity in the manufacturer DS. IDM provides a default Self-Regisration UI enabling your customers to register themselves through your website.

Figure 2.2. Creating a User Identity Through Self-Registration

For more information about self-registration see the following topics in the Identity Management product documentation:

In this use case, the end user pushes the smart speaker ON button. The smart speaker "calls home," attempting to communicate with its manufacturer. The communication is intercepted by AM, which requests the smart speaker credentials. The smart speaker presents the certificate provisioned at the factory, and AM issues a session ID and a token. Now authenticated, the smart speaker can begin its initial firmware download.

Figure 2.3. Smart Device Calls Home

For information about certificate-based authentication, see the following topics in the Access Management and Identity Gateway product documentation:

In this use case, the end user personalizes the smart speaker. OAuth 2.0 authorization links the end user identity to the smart speaker identity. Beyond merely establishing device ownership, once the identities are linked, the smart speaker is authorized to communicate with the manufacturer cloud API on the end user's behalf. In this use case, the end user authorizes the smart speaker to connect to the manufacturer cloud API each time the ON button is pushed.

OAuth 2.0 authorization is designed for smart devices that have limited user interfaces. In this use case, the smart speaker has only a power ON button and a small, one-line display screen. The end user starts the OAuth 2.0 process by pushing the smart speaker ON button for the first time. The following figure illustrates the OAuth 2.0 device authorization process.

Figure 2.4. Linking User and Device Identities Using OAuth 2.0

In this use case, the end user's friend has invited the end user to share a music playlist. The friend has created the playlist and stored it through a third-party music service. The smart speaker end user accesses the music service website using a laptop computer. AM provides a user-managed access (UMA) interface through which the end user can provide consent to third-party services. The following figure illustrates a typical UMA communication flow.

Figure 2.5. User-Managed Access

For more information about UMA, see the ForgeRock User-Managed Access (UMA) 2.0 Guide.

There will be times when you want to end the association between an end-user identity and the device identity. For example, the end user in our use case might lose the device, or sell the device to another person. In these situations, both the end user and device manufacturer will want to ensure that original device owner no longer has responsibility for any service charges associated with the device. The device manufacturer must also ensure that the original user identity—and any information contained in the original user profile—is not accessible to anyone who can access the device.

The following figure illustrates a typical communication flow for revoking the association between IoT user and smart device.

Figure 2.6. Smart Device Revocation

For more information about revoking authorization, see the following documentation:

You can protect your IoT cloud service by configuring IG to act as an OAuth 2.0 resource server. When resources are protected with OAuth 2.0, IoT users can use their credentials with an OAuth 2.0-compliant identity provider such as ForgeRock Access Manager, Facebook, Google, and others to access the resources. This eliminates the need for the IoT user to set up an account with yet another third-party application.

For more information about protecting IoT resources, see the Identity Gateway product documentation:

The ForgeRock Identity Platform is an early adopter of the OAuth 2.0 Proof of Possession (PoP) standard. PoP ensures that a bearer token, a token presented by a client, is presented by its rightful owner. A client could be a web browser accessing an application, or an IoT device connecting to a cloud service on behalf of an end user.

In the smart speaker use case, the manufacturer configured PoP as part of the OAuth 2.0 Device Flow that links the end user identity with the smart speaker identity. This protects against bearer token theft, and reduces the risk of man-in-the-middle attacks.

AM provides a transparent challenge/response-style interaction to prove the client is the intended owner of the access token. The client makes a normal request for an access token from the authorization service (AS), but the request includes an additional parameter. The parameter contains some public key infrastructure (PKI) data the client has access to. The PKI data is typically the public key of an asymmetric key pair.

This key is then baked into the access token. If the access token is a JWT, the JWT contains this public key. The JWT is then signed by the authorization service. If using a stateful access token, the AS token introspection endpoint can relay the public key back to the resource server at lookup time.

For more information about Proof of Possession, see the following topics in the AM product documentation:

IG provides a filter for regulating, or throttling, the number of requests an IoT user, device, or service can submit against a particular endpoint or set of endpoints. This helps prevent misuse of your cloud service or custom API. In the smart speaker use case, if the end user sends more requests than the number specified by the manufacturer, access to the server is denied.

For more information about using ThrottlingFilter, see Throttling Filters and Policies in the Identity Gateway product documentation.

The IMB is a publish-subscribe broker service that secures and hardens message transmission between IoT devices and cloud services. When an IoT device sends a request to a cloud service, following Access Management authentication, IMB does the following:

The IMB is ideal in IoT ecosystems where a lightweight publish-subscribe messaging service such as MQTT is already in place. For example, MQTT is often used with constrained IoT devices such as sensors that require low-level computing or communication capabilities. Sensors can collect and transmit data to cloud applications. The IMB secures data from such devices at the edge of the IoT ecosystem.

A conventional home air temperature thermostat is a good example of a simple sensor. The thermostat triggers home heating or cooling devices based on the temperature range the end user has configured. When the it's too cold in the house, the thermostat sends a message to the air heating system to change its state to ON. All of this happens within the physical boundaries of the home.

A wifi-enabled thermostat, an IoT device, can do much more when it connects to a cloud service. For example, the wifi-enabled thermostat might store information about the times of day the home heating and cooling devices turn on and off. When the thermostat connects to the internet, it publishes an MQTT message containing time-of-day, temperature, and status information. Its manufacturer receives the data by subscribing to messages from the thermostat. The cloud service can analyze the data over time. The cloud service then publishes MQTT messages for the thermostat. The thermostat subscribes to messages from the cloud service to receive refined settings for improved efficiency and cost savings.

The following figure illustrates the data flow among a wifi-enabled home thermostat, the IMB, and a cloud service.

Figure 4.1. Message Broker Secures Data At the Edge

In this use case, the IMB secures all publish and subscribe messages sent between a single home thermostat and its manufacturer's cloud service. A factory production line, a fleet of rental cars, or other commercial settings can have hundreds of thousands of registered IoT devices—each with its own identity—in constant communication with a myriad of cloud services. The IMB will scale to meet those needs.

For detailed information about deploying and configuring Identity Message Broker, see the User Guide.