Toegang tot IoT Hub beheren met handtekeningen voor gedeelde toegang

IoT Hub gebruikt SAS-tokens (Shared Access Signature) om apparaten en services te verifiëren om te voorkomen dat sleutels op de kabel worden verzonden. U gebruikt SAS-tokens om tijdgebonden toegang te verlenen tot apparaten en services voor specifieke functionaliteit in IoT Hub. Als u autorisatie wilt krijgen om verbinding te maken met IoT Hub, moeten apparaten en services SAS-tokens verzenden die zijn ondertekend met een gedeelde toegang of een symmetrische sleutel. Symmetrische sleutels worden opgeslagen met een apparaat-id in het identiteitsregister.

In dit artikel wordt het volgende besproken:

• De verschillende machtigingen die u aan een client kunt verlenen voor toegang tot uw IoT-hub.
• De tokens die IoT Hub gebruikt om machtigingen te verifiëren.
• Referenties instellen om de toegang tot specifieke resources te beperken.
• Aangepaste mechanismen voor apparaatverificatie die gebruikmaken van bestaande apparaat-id-registers of verificatieschema's.

Notitie

Sommige van de functies die in dit artikel worden genoemd, zoals cloud-naar-apparaat-berichten, apparaatdubbels en apparaatbeheer, zijn alleen beschikbaar in de standaardlaag van IoT Hub. Zie De juiste IoT Hub-laag voor uw oplossing kiezen voor meer informatie over de Basic- en Standard-/gratis IoT Hub-lagen.

IoT Hub gebruikt machtigingen om toegang te verlenen tot elk IoT Hub-eindpunt. Machtigingen beperken de toegang tot een IoT-hub op basis van functionaliteit. U moet over de juiste machtigingen beschikken om toegang te krijgen tot een van de IoT Hub-eindpunten. Een apparaat moet bijvoorbeeld een token bevatten met beveiligingsreferenties, samen met elk bericht dat het naar IoT Hub verzendt. De ondertekeningssleutels, zoals de symmetrische sleutels van het apparaat, worden echter nooit via de kabel verzonden.

Verificatie en autorisatie

Verificatie is het proces om aan te tonen dat u bent wie u zegt dat u bent. Verificatie controleert de identiteit van een gebruiker of apparaat naar IoT Hub. Het wordt soms ingekort tot AuthN. Autorisatie is het proces van het bevestigen van machtigingen voor een geverifieerde gebruiker of apparaat in IoT Hub. Hiermee geeft u op welke resources en opdrachten u toegang hebt en wat u kunt doen met deze resources en opdrachten. Autorisatie wordt soms ingekort tot AuthZ.

In dit artikel worden verificatie en autorisatie beschreven met handtekeningen voor gedeelde toegang, waarmee u machtigingen kunt groeperen en aan toepassingen kunt verlenen met behulp van toegangssleutels en ondertekende beveiligingstokens. U kunt ook symmetrische sleutels of gedeelde toegangssleutels gebruiken om een apparaat te verifiëren met IoT Hub. SAS-tokens bieden verificatie voor elke aanroep van het apparaat naar IoT Hub door de symmetrische sleutel aan elke aanroep te koppelen.

Toegangsbeheer en machtigingen

Gebruik beleid voor gedeelde toegang voor toegang op IoT-hubniveau en gebruik de referenties van het afzonderlijke apparaat om alleen toegang tot dat apparaat te bepalen.

Beleid voor gedeelde toegang op IoT Hub-niveau

Beleid voor gedeelde toegang kan elke combinatie van machtigingen verlenen. U kunt beleidsregels definiëren in Azure Portal, programmatisch met behulp van de IoT Hub Resource REST API's of met behulp van de Azure CLI az iot hub policy command. Een zojuist gemaakte IoT-hub heeft het volgende standaardbeleid:

Beleid voor gedeelde toegang	Machtigingen
iothubowner	Alle machtigingen
service	ServiceConnect-machtigingen
apparaat	DeviceConnect-machtigingen
registryRead	RegistryRead-machtigingen
registryReadWrite	RegistryRead- en RegistryWrite-machtigingen

U kunt de volgende machtigingen gebruiken om de toegang tot uw IoT-hub te beheren:

• De ServiceConnect-machtiging wordt gebruikt door back-endcloudservices en verleent de volgende toegang:

  • Toegang tot cloudservicegerichte communicatie- en bewakingseindpunten.
  • Ontvang apparaat-naar-cloud-berichten, verzend cloud-naar-apparaat-berichten en haal de bijbehorende bezorgingsbevestigingen op.
  • Haal bezorgingsbevestigingen op voor bestandsuploads.
  • Toegang tot dubbels om tags en gewenste eigenschappen bij te werken, gerapporteerde eigenschappen op te halen en query's uit te voeren.

• De machtiging DeviceConnect wordt door apparaten gebruikt en verleent de volgende toegang:

  • Toegang tot apparaatgerichte eindpunten.
  • Apparaat-naar-cloud-berichten verzenden en cloud-naar-apparaat-berichten ontvangen.
  • Uploaden van bestanden uitvoeren.
  • Ontvang meldingen van gewenste eigenschappen van apparaatdubbels en werk gerapporteerde eigenschappen van apparaatdubbel bij.

• De Machtiging RegistryRead wordt gebruikt door back-endcloudservices en verleent de volgende toegang:

  • Leestoegang tot het identiteitsregister. Zie Identiteitsregister voor meer informatie.

• De machtiging RegistryReadWrite wordt gebruikt door back-endcloudservices en verleent de volgende toegang:

  • Lees- en schrijftoegang tot het identiteitsregister. Zie Identiteitsregister voor meer informatie.

Beveiligingsreferenties per apparaat

Elke IoT-hub heeft een identiteitsregister waarin informatie wordt opgeslagen over de apparaten en modules die er verbinding mee mogen maken. Voordat een apparaat of module verbinding kan maken, moet er een vermelding zijn voor dat apparaat of die module in het identiteitsregister van de IoT Hub. Een apparaat of module wordt geverifieerd met de IoT-hub op basis van referenties die zijn opgeslagen in het identiteitsregister.

Wanneer u een apparaat registreert voor het gebruik van SAS-tokenverificatie, krijgt dat apparaat twee symmetrische sleutels. Symmetrische sleutels verlenen de DeviceConnect-machtiging voor de bijbehorende apparaat-id.

SAS-tokens van services gebruiken

Services kunnen SAS-tokens genereren met behulp van een beleid voor gedeelde toegang waarmee de juiste machtigingen worden gedefinieerd, zoals eerder is uitgelegd in het gedeelte Toegangsbeheer en machtigingen .

Een service die gebruikmaakt van het vooraf gemaakte beleid voor gedeelde toegang met de naam registryRead , maakt een token met de volgende parameters:

• resource-URI: {IoT hub name}.azure-devices.net,
• ondertekeningssleutel: een van de sleutels van het registryRead beleid,
• beleidsnaam: registryRead,
• elke verlooptijd.

Met de volgende code wordt bijvoorbeeld een SAS-token gemaakt in Node.js:

var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

Het resultaat, dat toegang verleent tot het lezen van alle apparaatidentiteiten in het identiteitsregister, is:

SharedAccessSignature sr=myhub.azure-devices.net&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead

Zie SAS-tokens genereren voor meer voorbeelden.

Voor services verlenen SAS-tokens alleen machtigingen op IoT Hub-niveau. Dat wil gezegd: een service die wordt geverifieerd met een token op basis van het servicebeleid , kan alle bewerkingen uitvoeren die zijn verleend door de ServiceConnect-machtiging . Deze bewerkingen omvatten het ontvangen van apparaat-naar-cloud-berichten, het verzenden van cloud-naar-apparaat-berichten, enzovoort. Als u meer gedetailleerde toegang wilt verlenen tot uw services, bijvoorbeeld door een service te beperken tot het alleen verzenden van cloud-naar-apparaat-berichten, kunt u Microsoft Entra ID gebruiken. Zie Verifiëren met Microsoft Entra ID voor meer informatie.

SAS-tokens van apparaten gebruiken

Er zijn twee manieren om DeviceConnect-machtigingen te verkrijgen met IoT Hub met SAS-tokens: gebruik een symmetrische apparaatsleutel uit het identiteitsregister of gebruik een gedeelde toegangssleutel.

Alle functionaliteit die toegankelijk is vanaf apparaten, wordt standaard beschikbaar gesteld op eindpunten met het voorvoegsel /devices/{deviceId}.

De apparaatgerichte eindpunten zijn (ongeacht het protocol):

Eindpunt	Functionaliteit
{iot hub name}/devices/{deviceId}/messages/events	Apparaat-naar-cloud-berichten verzenden.
{iot hub name}/devices/{deviceId}/messages/devicebound	Cloud-naar-apparaat-berichten ontvangen.

Een symmetrische sleutel gebruiken in het identiteitsregister

Wanneer u de symmetrische sleutel van een apparaat-id gebruikt om een token te genereren, wordt het element policyName (skn) van het token weggelaten.

Een token dat is gemaakt voor toegang tot alle apparaatfunctionaliteit, moet bijvoorbeeld de volgende parameters hebben:

• resource-URI: {IoT hub name}.azure-devices.net/devices/{device id},
• ondertekeningssleutel: elke symmetrische sleutel voor de {device id} identiteit,
• geen beleidsnaam,
• elke verlooptijd.

Met de volgende code wordt bijvoorbeeld een SAS-token gemaakt in Node.js:

var endpoint ="myhub.azure-devices.net/devices/device1";
var deviceKey ="...";

var token = generateSasToken(endpoint, deviceKey, null, 60);

Het resultaat, dat toegang verleent tot alle functionaliteit voor apparaat1, is:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697

Zie SAS-tokens genereren voor meer voorbeelden.

Een beleid voor gedeelde toegang gebruiken voor toegang namens een apparaat

Wanneer u een token maakt op basis van een beleid voor gedeelde toegang, stelt u het skn veld in op de naam van het beleid. Dit beleid moet de DeviceConnect-machtiging verlenen.

De twee belangrijkste scenario's voor het gebruik van beleid voor gedeelde toegang tot apparaatfunctionaliteit zijn:

• cloudprotocolgateways,
• tokenservices die worden gebruikt voor het implementeren van aangepaste verificatieschema's.

Omdat het beleid voor gedeelde toegang mogelijk toegang kan verlenen om verbinding te maken als elk apparaat, is het belangrijk om de juiste bron-URI te gebruiken bij het maken van SAS-tokens. Deze instelling is vooral belangrijk voor tokenservices, die het token moeten instellen op een specifiek apparaat met behulp van de resource-URI. Dit punt is minder relevant voor protocolgateways omdat ze al verkeer mediateren voor alle apparaten.

Als voorbeeld maakt een tokenservice met behulp van het vooraf gemaakte beleid voor gedeelde toegang met de naam apparaat een token met de volgende parameters:

• resource-URI: {IoT hub name}.azure-devices.net/devices/{device id},
• ondertekeningssleutel: een van de sleutels van het device beleid,
• beleidsnaam: device,
• elke verlooptijd.

Met de volgende code wordt bijvoorbeeld een SAS-token gemaakt in Node.js:

var endpoint ="myhub.azure-devices.net/devices/device1";
var policyName = 'device';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

Het resultaat, dat toegang verleent tot alle functionaliteit voor apparaat1, is:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697&skn=device

Een protocolgateway kan hetzelfde token voor alle apparaten gebruiken door de resource-URI in te stellen op myhub.azure-devices.net/devices.

Zie SAS-tokens genereren voor meer voorbeelden.

Een tokenservice maken om bestaande apparaten te integreren

U kunt het IoT Hub-identiteitsregister gebruiken om beveiligingsreferenties per apparaat of per module te configureren en toegangsbeheer te gebruiken met behulp van tokens. Als een IoT-oplossing al een aangepast identiteitsregister en/of verificatieschema heeft, kunt u overwegen om een tokenservice te maken om deze infrastructuur te integreren met IoT Hub. Op deze manier kunt u andere IoT-functies in uw oplossing gebruiken.

Een tokenservice is een aangepaste cloudservice. Er wordt gebruikgemaakt van een gedeeld toegangsbeleid voor IoT Hub met de machtiging DeviceConnect om tokens met apparaatbereik of modulebereik te maken. Met deze tokens kan een apparaat of module verbinding maken met uw IoT-hub.

Hier volgen de belangrijkste stappen van het tokenservicepatroon:

1. Maak een gedeeld toegangsbeleid voor IoT Hub met de machtiging DeviceConnect voor uw IoT-hub. U kunt dit beleid maken in Azure Portal of programmatisch. De tokenservice gebruikt dit beleid om de tokens te ondertekenen die worden gemaakt.

2. Wanneer een apparaat of module toegang nodig heeft tot uw IoT-hub, vraagt het een ondertekend token aan bij uw tokenservice. Het apparaat kan worden geverifieerd met uw aangepaste identiteitsregister/verificatieschema om de apparaat-/module-id te bepalen die de tokenservice gebruikt om het token te maken.

3. De tokenservice retourneert een token. Het token wordt gemaakt met behulp van /devices/{deviceId} of /devices/{deviceId}/modules/{moduleId} als resourceURI, met deviceId als het apparaat dat wordt geverifieerd en moduleId als de module die wordt geverifieerd. De tokenservice maakt gebruik van het beleid voor gedeelde toegang om het token samen te stellen.

4. Het apparaat/de module gebruikt het token rechtstreeks met de IoT-hub.

Notitie

U kunt de .NET-klasse SharedAccessSignatureBuilder of de Java-klasse IotHubServiceSasToken gebruiken om een token te maken in uw tokenservice.

De tokenservice kan de vervaldatum van het token naar wens instellen. Wanneer het token verloopt, verbreekt de IoT-hub de apparaat-/moduleverbinding. Vervolgens moet het apparaat/de module een nieuw token aanvragen bij de tokenservice. Een korte verlooptijd verhoogt de belasting van zowel het apparaat/de module als de tokenservice.

Als u een apparaat/module wilt verbinden met uw hub, moet u het nog steeds toevoegen aan het IoT Hub-identiteitsregister, ook al gebruikt u een token en geen sleutel om verbinding te maken. Daarom kunt u toegangsbeheer per apparaat/per module blijven gebruiken door apparaat-/module-id's in of uit te schakelen in het identiteitsregister. Deze aanpak beperkt de risico's van het gebruik van tokens met lange verlooptijden.

Vergelijking met een aangepaste gateway

Het tokenservicepatroon is de aanbevolen manier om een aangepast identiteitsregister/verificatieschema te implementeren met IoT Hub. Dit patroon wordt aanbevolen omdat IoT Hub het grootste deel van het oplossingsverkeer blijft verwerken. Als het aangepaste verificatieschema echter zo verstrengeld is met het protocol, is het mogelijk dat u een aangepaste gateway nodig hebt om al het verkeer te verwerken. Een voorbeeld van een dergelijk scenario is het gebruik van TLS (Transport Layer Security) en vooraf gedeelde sleutels (PSK's). Zie Hoe een IoT Edge-apparaat kan worden gebruikt als gateway voor meer informatie.

SAS-tokens genereren

Azure IoT SDK's genereren automatisch tokens, maar voor sommige scenario's moet u SAS-tokens rechtstreeks genereren en gebruiken, waaronder:

• Het directe gebruik van de MQTT-, AMQP- of HTTPS-oppervlakken.

• De implementatie van het tokenservicepatroon, zoals wordt uitgelegd in de sectie Een tokenservice maken.

Een token dat is ondertekend met een gedeelde toegangssleutel verleent toegang tot alle functionaliteit die is gekoppeld aan de machtigingen voor gedeeld toegangsbeleid. Een token dat is ondertekend met de symmetrische sleutel van een apparaat-id verleent alleen de DeviceConnect-machtiging voor de bijbehorende apparaat-id.

In deze sectie vindt u voorbeelden van het genereren van SAS-tokens in verschillende codetalen. U kunt ook SAS-tokens genereren met de CLI-extensieopdracht az iot hub generate-sas-token of de Azure IoT Hub-extensie voor Visual Studio Code.

SAS-tokenstructuur

Een SAS-token heeft de volgende indeling:

SharedAccessSignature sig={signature-string}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}

Dit zijn de verwachte waarden:

Weergegeven als	Beschrijving
{signature}	Een HMAC-SHA256-handtekeningtekenreeks van het formulier: {URL-encoded-resourceURI} + "\n" + expiry. Belangrijk: De sleutel wordt gedecodeerd uit base64 en gebruikt als sleutel om de HMAC-SHA256-berekening uit te voeren.
{resourceURI}	URI-voorvoegsel (per segment) van de eindpunten die kunnen worden geopend met dit token, te beginnen met de hostnaam van de IoT-hub (geen protocol). SAS-tokens die worden verleend aan back-endservices, zijn gericht op ioT-hubniveau; bijvoorbeeld myHub.azure-devices.net. SAS-tokens die aan apparaten worden verleend, moeten worden beperkt tot een afzonderlijk apparaat; bijvoorbeeld myHub.azure-devices.net/devices/device1.
{vervaldatum}	UTF8-tekenreeksen voor het aantal seconden sinds het tijdvak 00:00:00 UTC op 1 januari 1970.
{URL-gecodeerde-resourceURI}	URL-codering van kleine letters van de resource-URI met kleine letters
{policyName}	De naam van het beleid voor gedeelde toegang waarnaar dit token verwijst. Afwezig als het token verwijst naar de referenties van het apparaatregister.

Het URI-voorvoegsel wordt berekend op segment en niet op teken. Is bijvoorbeeld /a/b een voorvoegsel voor /a/b/c maar niet voor /a/bc.

Node.js

Met de volgende code wordt een SAS-token gegenereerd met behulp van de resource-URI, ondertekeningssleutel, beleidsnaam en verloopperiode. In de volgende secties wordt beschreven hoe u de verschillende invoer voor de verschillende tokengebruiksscenario's initialiseert.

var generateSasToken = function(resourceUri, signingKey, policyName, expiresInMins) {
    resourceUri = encodeURIComponent(resourceUri);

    // Set expiration in seconds
    var expires = (Date.now() / 1000) + expiresInMins * 60;
    expires = Math.ceil(expires);
    var toSign = resourceUri + '\n' + expires;

    // Use crypto
    var hmac = crypto.createHmac('sha256', Buffer.from(signingKey, 'base64'));
    hmac.update(toSign);
    var base64UriEncoded = encodeURIComponent(hmac.digest('base64'));

    // Construct authorization string
    var token = "SharedAccessSignature sr=" + resourceUri + "&sig="
    + base64UriEncoded + "&se=" + expires;
    if (policyName) token += "&skn="+policyName;
    return token;
};

Python

Met de volgende code wordt een SAS-token gegenereerd met behulp van de resource-URI, ondertekeningssleutel, beleidsnaam en verloopperiode. In de volgende secties wordt beschreven hoe u de verschillende invoer voor de verschillende tokengebruiksscenario's initialiseert.

from base64 import b64encode, b64decode
from hashlib import sha256
from time import time
from urllib import parse
from hmac import HMAC

def generate_sas_token(uri, key, policy_name, expiry=3600):
    ttl = time() + expiry
    sign_key = "%s\n%d" % ((parse.quote_plus(uri)), int(ttl))
    print(sign_key)
    signature = b64encode(HMAC(b64decode(key), sign_key.encode('utf-8'), sha256).digest())

    rawtoken = {
        'sr' :  uri,
        'sig': signature,
        'se' : str(int(ttl))
    }

    if policy_name is not None:
        rawtoken['skn'] = policy_name

    return 'SharedAccessSignature ' + parse.urlencode(rawtoken)

C#

Met de volgende code wordt een SAS-token gegenereerd met behulp van de resource-URI, ondertekeningssleutel, beleidsnaam en verloopperiode. In de volgende secties wordt beschreven hoe u de verschillende invoer voor de verschillende tokengebruiksscenario's initialiseert.

using System;
using System.Globalization;
using System.Net;
using System.Net.Http;
using System.Security.Cryptography;
using System.Text;

public static string GenerateSasToken(string resourceUri, string key, string policyName, int expiryInSeconds = 3600)
{
    TimeSpan fromEpochStart = DateTime.UtcNow - new DateTime(1970, 1, 1);
    string expiry = Convert.ToString((int)fromEpochStart.TotalSeconds + expiryInSeconds);

    string stringToSign = WebUtility.UrlEncode(resourceUri) + "\n" + expiry;

    HMACSHA256 hmac = new HMACSHA256(Convert.FromBase64String(key));
    string signature = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(stringToSign)));

    string token = String.Format(CultureInfo.InvariantCulture, "SharedAccessSignature sr={0}&sig={1}&se={2}", WebUtility.UrlEncode(resourceUri), WebUtility.UrlEncode(signature), expiry);

    if (!String.IsNullOrEmpty(policyName))
    {
        token += "&skn=" + policyName;
    }

    return token;
}

Java

Met de volgende code wordt een SAS-token gegenereerd met behulp van de resource-URI en ondertekeningssleutel. De verloopperiode is ingesteld op één uur vanaf de huidige tijd. In de volgende secties wordt beschreven hoe u de verschillende invoer voor de verschillende tokengebruiksscenario's initialiseert.

public static String generateSasToken(String resourceUri, String key) throws Exception {
    // Token will expire in one hour
    var expiry = Instant.now().getEpochSecond() + 3600;

    String stringToSign = URLEncoder.encode(resourceUri, StandardCharsets.UTF_8) + "\n" + expiry;
    byte[] decodedKey = Base64.getDecoder().decode(key);

    Mac sha256HMAC = Mac.getInstance("HmacSHA256");
    SecretKeySpec secretKey = new SecretKeySpec(decodedKey, "HmacSHA256");
    sha256HMAC.init(secretKey);
    Base64.Encoder encoder = Base64.getEncoder();

    String signature = new String(encoder.encode(
        sha256HMAC.doFinal(stringToSign.getBytes(StandardCharsets.UTF_8))), StandardCharsets.UTF_8);

    String token = "SharedAccessSignature sr=" + URLEncoder.encode(resourceUri, StandardCharsets.UTF_8)
            + "&sig=" + URLEncoder.encode(signature, StandardCharsets.UTF_8.name()) + "&se=" + expiry;
            
    return token;
}

Protocolspecifieke gegevens

Elk ondersteund protocol, zoals MQTT, AMQP en HTTPS, transporteert tokens op verschillende manieren.

Wanneer u MQTT gebruikt, heeft het CONNECT-pakket de deviceId als de ClientId, {iothubhostname}/{deviceId} in het veld Gebruikersnaam en een SAS-token in het veld Wachtwoord. {iothubhostname} moet de volledige CName van de IoT-hub zijn (bijvoorbeeld myhub.azure-devices.net).

Wanneer u AMQP gebruikt, ondersteunt IoT Hub SASL PLAIN en AMQP Claims-Based-Security.

Als u beveiliging op basis van AMQP-claims gebruikt, geeft de standaard aan hoe deze tokens moeten worden verzonden.

Voor SASL PLAIN kan de gebruikersnaam het volgende zijn:

• {policyName}@sas.root.{iothubName} als u tokens op IoT-hubniveau gebruikt.
• {deviceId}@sas.{iothubname} als u tokens met apparaatbereik gebruikt.

In beide gevallen bevat het wachtwoordveld het token, zoals beschreven in de SAS-tokenstructuur.

HTTPS implementeert verificatie door een geldig token op te geven in de header van de autorisatieaanvraag .

Gebruikersnaam (DeviceId is bijvoorbeeld hoofdlettergevoelig): iothubname.azure-devices.net/DeviceId

Wachtwoord (u kunt een SAS-token genereren met de CLI-extensieopdracht az iot hub generate-sas-token of de Azure IoT Hub-extensie voor Visual Studio Code):

SharedAccessSignature sr=iothubname.azure-devices.net%2fdevices%2fDeviceId&sig=kPszxZZZZZZZZZZZZZZZZZAhLT%2bV7o%3d&se=1487709501

Notitie

De Azure IoT SDK's genereren automatisch tokens bij het maken van verbinding met de service. In sommige gevallen ondersteunen de Azure IoT SDK's niet alle protocollen of alle verificatiemethoden.

Speciale overwegingen voor SASL PLAIN

Wanneer u SASL PLAIN met AMQP gebruikt, kan een client die verbinding maakt met een IoT-hub één token gebruiken voor elke TCP-verbinding. Wanneer het token verloopt, verbreekt de TCP-verbinding de verbinding met de service en wordt opnieuw verbinding gemaakt. Dit gedrag, hoewel dit niet problematisch is voor een back-end-app, is om de volgende redenen schadelijk voor een apparaat-app:

• Gateways maken meestal verbinding namens veel apparaten. Wanneer u SASL PLAIN gebruikt, moeten ze een afzonderlijke TCP-verbinding maken voor elk apparaat dat verbinding maakt met een IoT-hub. Dit scenario verhoogt het verbruik van energie- en netwerkresources aanzienlijk en verhoogt de latentie van elke apparaatverbinding.

• Apparaten met beperkte resources worden nadelig beïnvloed door het toegenomen gebruik van resources om opnieuw verbinding te maken nadat elk token is verlopen.

Volgende stappen

Nu u hebt geleerd hoe u toegang tot IoT Hub kunt beheren, bent u mogelijk geïnteresseerd in de volgende onderwerpen over de ontwikkelaarshandleiding voor IoT Hub:

• Apparaatdubbels gebruiken om status en configuraties te synchroniseren
• Een directe methode aanroepen op een apparaat
• Taken op meerdere apparaten plannen