This is example code to show how to manage an Azure IoT hub from an Azure function
More infos soon on https://blogs.msdn.com/b/holgerkenn/
Includes a .net core client example.
Unmodified, it allows to register IOT Devices with Azure IoT hub with a simple REST function call that returns a device connection string.
This can either be used to pre-register IoT devices during production (e.g. simple devices like the teXXmo IoT Button https://github.com/teXXmo/TheButtonProject ) or it can be used for devices to self-register with an IoT hub if they cannot use Azure IoT DPS service https://docs.microsoft.com/en-us/azure/iot-dps/ when no factory provisioning, device-individual certificates, HSMs or TPMs are available.
** Please do your own threat analysis before using this approach. DPS is the more secure approach, if you can use DPS, then use it! **
The service and the sample client program needs to be configured.
To configure the service, open the application settings of your function app and enter the following under Application Settings (don't use the connection string section!)
IoTHub <your iot hub owner connection string goes here>
validation key <your sas validation key goes here, see below>
To configure the client, create an appsettings.json file and enter the following:
{
"functionKey": "<your function key goes here, see below>",
"validationKey": "<your sas validation key goes here, see below>",
"serviceURL": "https://<your azure function name goes here>.azurewebsites.net/api/NewDevice"
}
The service relies on a number of secrets.
To access an Azure function, an access key is needed. This key is auto-generated by Azure. To enable the client sample to use the function, the function key needs to be entered into the appsettings file.
To authenticate each individual call, the service uses a shared access signature which is generated using a key. In needs to be entered as validationKey both in the service configuration and in the sample client configuration. To generate such a key, use the command line tool GenKey which is included in this repository. The SAS approach protects the key from interception by an attacker "in flight". Even if an attacker intercepts a valid SAS, this SAS is only valid for a limited amount of time and only for a specific device.
This approach does not protect the key from an attacker that has access to the client software. Since the key has to be included in the client, it can be obtained by an attacker using reverse engineering the client code. If this approach is insufficient for your security requirements, use Azure IoT DPS.
See LICENSE for (MIT) License Information.