Support multitenant solutions in IoT Hub
I want to allow each tenant to connect directly to IoT hub (as service) to communicate with devices. Of course I would want each tenant to have access only to their own devices and not have the possibility to connect to devices from other tenants (thus I require the proper SAS).Following the documentation on the ServiceConnect permissions, it would seem that it is not possible to do this restriction on a SAS level.
Elio Damaggio
shared this idea
8 comments
-
Alex Bedig
commented
We are considering the tradeoffs of IoT Hub -> Event Hub vs. APIM -> Event Hub for 'unmanaged devices' - scenarios where another system manages updating an API key, that want to HTTP POST their telemetry data via applications we do not control.
If the goal is to use SAS tokens with HTTP POST with IoT Hub, the 365-day maximum SAS token lifetime seems like a blocker, or at least another responsibility for that application we do not control to manage.
Assuming we can get around that: because we do not control the applications, we assume we need ways to limit the impact of *devices* behaving badly, i.e. per-device throttling. But, we are willing to impose fairly severe limits on what devices are allowed to do - these are legacy devices after all.
It seems the 'IoT Hub way' would be to create a different IoT hub for each tenant, so that at least the worst a customer could do is take down only their own devices on our platform. Since each Azure subscription can have 50 IoT hubs (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling), that gives us some room but doesn't seem exactly right either.
One leading alternative is to use Client Driven Throttling (https://docs.microsoft.com/en-us/azure/api-management/api-management-sample-flexible-throttling#client-driven-throttling) along with an HMAC-based API key verification process to rate-limit every device. The downside here is implementing our own API key verification process, although APIM has the dependencies it needs to do an HMAC integrity check easily.
The other upside of APIM is it currently supports custom domains, i.e. we do not have to get stuck with devices in the field reporting to Azure-owned domain names (assuming I'm reading this correctly here: https://feedback.azure.com/forums/321918-azure-iot/suggestions/17908789-add-the-custom-domain-name-support-for-iothub-endp).
IoT Hub looks attractive when we are deploying a fleet of our own devices, especially if we can control or verify the applications that are running on them. It seems like it is not the simplest to work with for more "at arm's length" devices that customers want to ship data from without necessarily replacing, and that use a wide range of data management applications (i.e. HTTP POST is a least-common-denominator).
I would be interested in how the IoT Hub team thinks about this scenario. If "it won't work at scale" is part of the answer, I can appreciate that perspective.
-
Alex Bedig
commented
We are considering the tradeoffs of IoT Hub -> Event Hub vs. APIM -> Event Hub for 'unmanaged devices' - scenarios where another system manages updating an API key, that want to HTTP POST their telemetry data via applications we do not control.
If the goal is to use SAS tokens with HTTP POST with IoT Hub, the 365-day maximum SAS token lifetime seems like a blocker, or at least another responsibility for that application we do not control to manage.
Assuming we can get around that: because we do not control the applications, we assume we need ways to limit the impact of *devices* behaving badly, i.e. per-device throttling. But, we are willing to impose fairly severe limits on what devices are allowed to do - these are legacy devices after all.
It seems the 'IoT Hub way' would be to create a different IoT hub for each tenant, so that at least the worst a customer could do is take down only their own devices on our platform. Since each Azure subscription can have 50 IoT hubs (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling), that gives us some room but doesn't seem exactly right either.
One leading alternative is to use Client Driven Throttling (https://docs.microsoft.com/en-us/azure/api-management/api-management-sample-flexible-throttling#client-driven-throttling) along with an HMAC-based API key verification process to statelessly rate-limit every device. The downside here is implementing our own API key verification process, although APIM has the dependencies it needs to do an HMAC integrity check easily.
The other upside of APIM is it currently supports custom domains, i.e. we do not have to get stuck with devices in the field reporting to Azure-owned domain names (assuming I'm reading this correctly here: https://feedback.azure.com/forums/321918-azure-iot/suggestions/17908789-add-the-custom-domain-name-support-for-iothub-endp).
IoT Hub looks attractive when we are deploying a fleet of our own devices, especially if we can control or verify the applications that are running on them. It seems like it is not the simplest to work with for more "at arm's length" devices that customers want to ship data from without necessarily replacing, and that use a wide range of data management applications (i.e. HTTP POST is a least-common-denominator).
I would be interested in how the IoT Hub team thinks about this scenario. If "it won't work at scale" is part of the answer, I can appreciate that perspective.
-
Till Maurer
commented
I would not expose Iot-hub directly to tenant applications. You would have no way of throttling requests. Who would pay the bill?
-
Johan Normén
commented
We are in big needs of this. Now they are looking at other cloud providers. And that's sad thought we wanted to have 100% azure only services.
But we are in deeply need of use one iot hub solution with many tenants. Because of reuse of message routines etc... and we are also building a PaaS solution.
-
Anonymous
commented
How close does IoT Central come to achieving this objective?
-
Bosko Bob Loncar commented
This is essential for any hardware/software as a service application
-
Anonymous
commented
I think it is a great idea since:
From current Azure IoT architecture, one big back-end control all things. but some cases is, IoT company focus on maintain Things like upgrade SW, and end-user will configure the thing they pay to, like connect this Thing to other Thing or establish rule between Things belong to different company.For this case, multi-tenant solution will be effective solution.
Best Regards
-
Ted van der Veen
commented
As a half baked workaround: If a single device can be controlled from the cloud by a maximum of one tenant then you may implement cryptographically random and hard to guess deviceId and share deviceId with the correct tenant only. But it gets messy fast of course and does not allow more complex multitenant setups