Azure IoT Identity Service — Use Identities Like a Boss

Have you heard about the new Azure IoT Identity Service yet? If not, you definitely want to check it out! It is used in IoT Edge 1.2.x but can also be used as a standalone service allowing you to integrate your applications (agents) with Azure IoT in a really easy way.

This is what the anatomy of the Azure IoT Identity Services looks like:

Azure IoT Identity Service

It is available as aziot-identity-service package and can be of course built from source code. What those individual systemd services actually do is documented here.

Azure IoT Identity Service supports different types of identities: device and module. Module identities are e.g. used by IoT Edge to make sure that every module gets its own identity within the scope of a device. One could also use this concept to provide identities to different components of a composite application. The support for authentication types varies between these identity types. At the time of writing it looks like this:

Identity types vs. Authentication types

Why use the Identity Service?

Well, Azure IoT Identity Service lets you focus more on your application (agent) that you want to integrate with Azure IoT. It handles the complexity of generating keys, requesting certificates, integrating with HSMs, provisioning with DPS and IoT Hub. Here are some highlights of the Azure IoT Identity Service:

1. Easy usage of module identities. The device identity is more privileged than a module identity as it has ownership of the module identities. Thus module identities provide better isolation for the components of a composite application. Another aspect is that IoT Hub will reject multiple simultaneous connection from the same device identity whereas it is possible to have multiple simultaneous connections using module identities in the scope of the same device. Azure IoT Identity Service takes care of creation/deletion/update of module identities in IoT Hub. Without it, one would need to implement this logic.
2. Enrollment over Secure Transport (EST) integration. Azure IoT Identity Service is capable of automatically requesting x509 certificates needed to enroll with Azure IoT from an EST endpoint and only needs to be configured appropriately. This is more than just submitting an HTTP request and involves activities such as key pair generation (optionally in hardware), creating a CSR, getting a certificate and storing it.
3. Hardware security module/chip integration. Instead of using low level APIs for the interaction with an HSM, Azure IoT Identity Service offers higher level APIs through Unix Domain Sockets and interacts with an HSM on your behalf.
4. If there is a mix of IoT Edge and regular IoT devices, Azure IoT Identity Service can be used in the same way with both to address common provisioning concerns and more.

I could add even more to this list but I believe the idea is clear: in some situations Azure IoT Identity Service can significantly reduce the development effort and time to market and at the same time you benefit from the support and security hardening Microsoft offers.

How do I use it?

First of all Azure IoT Identity Service needs to be installed and configured (please refer to this documentation). Then an application interacts with the individual services via Unix Domain Sockets to retrieve provisioned identity details, sign a SAS token, retrieve/request a certificate etc. An OpenSSL engine (for the Keys Service) that can be used with Azure IoT Device SDKs to enable processes to perform mTLS with DPS/IoT Hub is provided as well. In this GitHub repo you will find a sample using a module Identity to interact with IoT Hub using SAS token based authentication and one using a device identity with x509 certificate based authentication with the private key backed by TPM 2.0. The latter uses the OpenSSL engine provided by the Keys Service (“aziot_keys”). The setup looks like this:

Custom Agent flow with Azure IoT Identity Service

IoT Identity Service vs. IoT Device SDKs

With Azure IoT Identity Service we get yet another option for identity management with Azure IoT. This also raises the question of how these options compare to each other.

First of all I’d like to make clear that with regard to the DPS and IoT Hub interaction, the responsibility of Azure IoT Identity service is to provision a device in a secure way also automating many steps in between. It will not listen to Direct Methods, C2D messages or send telemetry to IoT Hub, this will be part of the application (agent) logic you develop, e.g. using an IoT Device SDK.

After a device is successfully provisioned one would use Azure IoT Identity Service to e.g. query the identity information, sign a SAS token with a key stored in HSM (as part of putting together a connection string for a module identity), sign a CSR which can be send to an external CA, request a certificate issued by a local CA and more. While this can be also done using custom code it would require some development effort, security hardening and increase total cost of ownership (TCO).

When could Azure IoT Identity Service be an overkill? I believe that Azure IoT Identity Service is most valuable when the identity setup is rather complex. Consider the following examples illustrating two ends of the spectrum. Let’s start with a more complex one:

We have a mix of IoT Edge and regular IoT devices. All devices have hardware security modules of different kinds (but supporting PKCS#11). Devices authenticate using x509 client certificates with DPS/IoT Hub and need to support zero touch provisioning and automatically request certificates from a CA through EST. Our application consists of a number of independent components working together. Most components (modules) require an IoT Hub connection since they can be controlled from the Cloud or need to send data to a Cloud application. Furthermore these components need to authenticate to external systems using x509 client certificates which they need to request automatically making sure that the private key does not leak.

I believe in situations like this Azure IoT Identity Service would be very valuable for reasons described in the “Why use the Identity Service?” section. A much simpler setup could look like this:

We just have regular IoT Devices which do not have any hardware security modules. There is currently no PKI and paying for one is not feasible. Also some of the devices are very resource constrained and could not handle x509 certificates. We use SAS token authentication to connect to IoT Hub and the application consists of a single monolithic component.

In this case Azure IoT Identity service does not really bring much value to the table and would even add complexity and consume additional resources. An IoT Device SDK would be more appropriate.

While both examples are contrived and may seem extreme, I believe they mark two ends of the spectrum showing where Azure IoT Identity Service can unfold its potential. The truth will most probably lie somewhere in between but I hope that these examples demonstrate enough of the thought process to help with the decision making.

Conclusion

Azure IoT Identity Service is a great solution which takes care of a number of low level aspects when it comes to enabling zero touch provisioning experience but may not be a good fit in every situation. Also you might encounter certain limitations, like the one known to me: Azure IoT Identity Service does not yet support passing a custom payload to DPS - something that would be needed for a PnP device intended to connect to IoT Central. Make sure to evaluate it thoroughly.

Do you think the identity service can help your scenario? Let me know in the comments.