Kontrolowanie dostępu do usługi IoT Hub przy użyciu sygnatur dostępu współdzielonego

Usługa IoT Hub używa tokenów sygnatury dostępu współdzielonego (SAS) do uwierzytelniania urządzeń i usług w celu uniknięcia wysyłania kluczy w sieci. Tokeny SAS służą do udzielania ograniczonego czasowo dostępu do urządzeń i usług określonym funkcjom w usłudze IoT Hub. Aby uzyskać autoryzację w celu nawiązania połączenia z usługą IoT Hub, urządzenia i usługi muszą wysyłać tokeny SAS podpisane przy użyciu klucza dostępu współdzielonego lub klucza symetrycznego. Klucze symetryczne są przechowywane z tożsamością urządzenia w rejestrze tożsamości.

W tym artykule przedstawiono następujące elementy:

Różne uprawnienia, które można udzielić klientowi w celu uzyskania dostępu do centrum IoT.
Tokeny usługi IoT Hub używają do weryfikowania uprawnień.
Określanie zakresu poświadczeń w celu ograniczenia dostępu do określonych zasobów.
Niestandardowe mechanizmy uwierzytelniania urządzeń korzystające z istniejących rejestrów tożsamości urządzeń lub schematów uwierzytelniania.

Uwaga

Niektóre funkcje wymienione w tym artykule, takie jak wysyłanie wiadomości z chmury do urządzenia, bliźniacze obiekty urządzeń i zarządzanie urządzeniami, są dostępne tylko w standardowej warstwie usługi IoT Hub. Aby uzyskać więcej informacji na temat warstw podstawowej i standardowej/bezpłatnej usługi IoT Hub, zobacz Wybieranie odpowiedniej warstwy i rozmiaru usługi IoT Hub dla rozwiązania.

Usługa IoT Hub używa uprawnień w celu udzielenia dostępu do każdego punktu końcowego centrum IoT. Uprawnienia ograniczają dostęp do centrum IoT w oparciu o funkcjonalność. Aby uzyskać dostęp do dowolnego z punktów końcowych usługi IoT Hub, musisz mieć odpowiednie uprawnienia. Na przykład urządzenie musi zawierać token zawierający poświadczenia zabezpieczeń wraz z każdym komunikatem wysyłanym do usługi IoT Hub. Jednak klucze podpisywania, takie jak klucze symetryczne urządzenia, nigdy nie są wysyłane za pośrednictwem przewodu.

Uwierzytelnianie i autoryzacja

Uwierzytelnianie to proces potwierdzania, że jesteś tym, kim jesteś. Uwierzytelnianie weryfikuje tożsamość użytkownika lub urządzenia w usłudze IoT Hub. Uwierzytelnianie jest czasami skracane do AuthN. Autoryzacja to proces potwierdzania uprawnień dla uwierzytelnionego użytkownika lub urządzenia w usłudze IoT Hub. Autoryzacja określa zasoby i polecenia, do których masz dostęp, oraz czynności, które można wykonać za pomocą tych zasobów i poleceń. Autoryzacja jest czasami skracana do AuthZ.

W tym artykule opisano uwierzytelnianie i autoryzację przy użyciu sygnatur dostępu współdzielonego, które umożliwiają grupowanie uprawnień i przyznawanie ich aplikacjom przy użyciu kluczy dostępu i podpisanych tokenów zabezpieczających. Możesz również użyć kluczy symetrycznych lub kluczy dostępu współdzielonego do uwierzytelniania urządzenia w usłudze IoT Hub. Tokeny SAS zapewniają uwierzytelnianie dla każdego wywołania wykonanego przez urządzenie w usłudze IoT Hub przez skojarzenie klucza symetrycznego z każdym wywołaniem.

Kontrola dostępu i uprawnienia

Użyj zasad dostępu współdzielonego dla dostępu na poziomie centrum IoT i użyj poświadczeń poszczególnych urządzeń, aby ograniczyć dostęp tylko do tego urządzenia.

Zasady dostępu współdzielonego na poziomie centrum IoT

Zasady dostępu współdzielonego mogą udzielać dowolnej kombinacji uprawnień. Zasady można definiować w portalu Azure, programowo przy użyciu interfejsów API REST zasobów usługi IoT Hub lub polecenia az iot hub policy platformy Azure CLI. Nowo utworzone centrum IoT ma następujące zasady domyślne:

Zasady dostępu współdzielonego	Uprawnienia
iothubowner	Wszystkie uprawnienia
usługa	Uprawnienia serviceConnect
urządzenie	Uprawnienia DeviceConnect
registryRead	Uprawnienia RegistryRead
odczyt i zapis w rejestrze	Uprawnienia RegistryRead i RegistryWrite

Aby kontrolować dostęp do centrum IoT Hub, możesz użyć następujących uprawnień:

Uprawnienie ServiceConnect jest używane przez usługi w chmurze zaplecza i udziela następującego dostępu:
- Dostęp do punktów końcowych komunikacji i monitorowania usług w chmurze.
- Odbieranie komunikatów z urządzenia do chmury, wysyłanie komunikatów z chmury do urządzenia i pobieranie odpowiednich potwierdzenia dostarczenia.
- Pobierz potwierdzenia odbioru dla przesyłania plików.
- Dostęp do bliźniaków cyfrowych w celu aktualizowania tagów i pożądanych właściwości, pobierania zgłoszonych właściwości i uruchamiania zapytań.
Uprawnienie DeviceConnect jest używane przez urządzenia i udziela następującego dostępu:
- Dostęp do punktów końcowych dla urządzeń.
- Wysyłanie komunikatów z urządzenia do chmury i odbieranie komunikatów z chmury do urządzenia.
- Wykonaj przekazywanie plików.
- Otrzymywanie powiadomień o żądanej właściwości bliźniaczej urządzenia i aktualizowanie zgłoszonych właściwości bliźniaczej urządzenia.
Uprawnienie RegistryRead jest używane przez usługi w chmurze zaplecza i udziela następującego dostępu:
- Dostęp do odczytu rejestru tożsamości. Aby uzyskać więcej informacji, zobacz Omówienie rejestru tożsamości w centrum IoT.
Uprawnienie RegistryReadWrite jest używane przez usługi w chmurze zaplecza i udziela następującego dostępu:
- Dostęp do odczytu i zapisu w rejestrze tożsamości. Aby uzyskać więcej informacji, zobacz Omówienie rejestru tożsamości w centrum IoT.

Poświadczenia zabezpieczeń dla każdego urządzenia

Każde centrum IoT ma rejestr tożsamości, który przechowuje informacje o urządzeniach i modułach, które mogą się z nim łączyć. Aby urządzenie lub moduł mógł nawiązać połączenie, w rejestrze tożsamości centrum IoT musi istnieć wpis dla tego urządzenia lub modułu. Urządzenie lub moduł uwierzytelnia się w centrum IoT na podstawie poświadczeń przechowywanych w rejestrze tożsamości.

Podczas rejestrowania urządzenia w celu korzystania z uwierzytelniania tokenu SAS urządzenie otrzymuje dwa klucze symetryczne. Klucze symetryczne przyznają uprawnienie DeviceConnect dla skojarzonej tożsamości urządzenia.

Używanie tokenów SAS z usług

Usługi mogą generować tokeny SAS przy użyciu zasad dostępu współdzielonego, które definiują odpowiednie uprawnienia, jak wyjaśniono wcześniej w sekcji Kontrola dostępu i uprawnienia .

Na przykład usługa korzystająca ze wstępnie utworzonych zasad dostępu współdzielonego o nazwie registryRead tworzy token z następującymi parametrami:

URI zasobu: {IoT hub name}.azure-devices.net
klucz podpisywania: jeden z kluczy registryRead polityki,
nazwa zasad: registryRead,
dowolnego czasu wygaśnięcia.

Na przykład poniższy kod tworzy token SAS w Node.js:

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

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

Wynikiem, który udziela dostępu do odczytu wszystkich tożsamości urządzeń w rejestrze tożsamości, będzie:

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

Aby uzyskać więcej przykładów, zobacz Generowanie tokenów SAS.

W przypadku usług tokeny SAS udzielają uprawnień tylko na poziomie usługi IoT Hub. Oznacza to, że usługa uwierzytelniająca się przy użyciu tokenu na podstawie zasad usługi może wykonywać wszystkie operacje przyznane przez uprawnienie ServiceConnect . Operacje te obejmują odbieranie komunikatów z urządzenia do chmury, wysyłanie komunikatów z chmury do urządzenia itd. Jeśli chcesz udzielić bardziej szczegółowego dostępu do usług, na przykład ograniczając usługę tylko do wysyłania komunikatów z chmury do urządzeń, możesz użyć identyfikatora Entra firmy Microsoft. Aby dowiedzieć się więcej, zobacz Kontrola dostępu do usługi IoT Hub przy użyciu identyfikatora Entra firmy Microsoft.

Używanie tokenów SAS z urządzeń

Istnieją dwa sposoby uzyskiwania uprawnień deviceConnect z usługą IoT Hub z tokenami SAS: użyj symetrycznego klucza urządzenia z rejestru tożsamości lub użyj klucza dostępu współdzielonego.

Wszystkie funkcjonalności dostępne z urządzeń są celowo udostępniane w punktach końcowych z prefiksem /devices/{deviceId}.

Punkty końcowe dostępne dla urządzeń to (niezależnie od protokołu):

Punkt końcowy	Funkcje
`{iot hub name}/devices/{deviceId}/messages/events`	Wysyłanie komunikatów z urządzenia do chmury.
`{iot hub name}/devices/{deviceId}/messages/devicebound`	Odbieranie komunikatów z chmury do urządzenia.

Używanie klucza symetrycznego w rejestrze tożsamości

W przypadku użycia klucza symetrycznego tożsamości urządzenia w celu wygenerowania tokenu element policyName (skn) tokenu zostanie pominięty.

Na przykład token utworzony w celu uzyskania dostępu do wszystkich funkcji urządzenia powinien mieć następujące parametry:

identyfikator URI zasobu: {IoT hub name}.azure-devices.net/devices/{device id},
klucz podpisywania {device id} : dowolny klucz symetryczny dla tożsamości,
brak nazwy polityki
dowolny czas wygaśnięcia

Na przykład poniższy kod tworzy token SAS w Node.js:

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

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

Wynik, który zapewnia dostęp do wszystkich funkcji urządzenia device1, będzie:

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

Aby uzyskać więcej przykładów, zobacz Generowanie tokenów SAS.

Używanie zasad dostępu współdzielonego do uzyskiwania dostępu w imieniu urządzenia

Podczas tworzenia tokenu z polityki dostępu udostępnionego, ustaw pole skn na nazwę tej polityki. Ta polityka musi przyznać uprawnienie DeviceConnect.

Dwa główne scenariusze używania zasad dostępu współdzielonego w celu uzyskania dostępu do funkcji urządzeń to:

bramy protokołów w chmurze,
usługi tokenów używane do implementowania niestandardowych schematów uwierzytelniania.

Ponieważ zasady dostępu dzielonego mogą potencjalnie udzielić dostępu w celu nawiązania połączenia jako dowolnego urządzenia, ważne jest użycie poprawnego identyfikatora URI zasobów podczas tworzenia tokenów SAS. To ustawienie jest szczególnie ważne w przypadku usług tokenów, które muszą określać zakres tokenu dla określonego urządzenia przy użyciu identyfikatora URI zasobu. Ten punkt jest mniej istotny dla bram protokołów, ponieważ już pośredniczą w ruchu dla wszystkich urządzeń.

Na przykład usługa tokenu korzystająca ze wstępnie utworzonych zasad dostępu współdzielonego o nazwie urządzenie utworzy token z następującymi parametrami:

identyfikator URI zasobu: {IoT hub name}.azure-devices.net/devices/{device id},
klucz podpisu: jeden z kluczy polityki device.
nazwa zasad: device,
dowolnego czasu wygaśnięcia.

Na przykład poniższy kod tworzy token SAS w Node.js:

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

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

Wynik, który udziela dostępu do wszystkich funkcji urządzenia device1, to:

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

Brama protokołu może używać tego samego tokenu dla wszystkich urządzeń, ustawiając identyfikator URI zasobu na myhub.azure-devices.net/devices.

Aby uzyskać więcej przykładów, zobacz Generowanie tokenów SAS.

Tworzenie usługi tokenu w celu zintegrowania istniejących urządzeń

Za pomocą rejestru tożsamości usługi IoT Hub można skonfigurować poświadczenia zabezpieczeń poszczególnych urządzeń lub poszczególnych modułów oraz kontrolę dostępu przy użyciu tokenów. Jeśli rozwiązanie IoT ma już niestandardowy rejestr tożsamości i/lub schemat uwierzytelniania, rozważ utworzenie usługi tokenu w celu zintegrowania tej infrastruktury z usługą IoT Hub. W ten sposób możesz użyć innych funkcji IoT w swoim rozwiązaniu.

Usługa tokenu to niestandardowa usługa w chmurze. Używa ona zasad dostępu współdzielonego usługi IoT Hub z uprawnieniem DeviceConnect do tworzenia tokenów o zakresie urządzenia lub w zakresie modułu. Te tokeny umożliwiają urządzeniu lub modułowi łączenie się z centrum IoT Hub.

Diagram przedstawiający kroki wzorca usługi tokenu.

Poniżej przedstawiono główne kroki wzorca usługi tokenu:

Utwórz politykę dostępu współdzielonego dla centrum IoT Hub posiadającą uprawnienie DeviceConnect. Te zasady można utworzyć w witrynie Azure Portal lub programowo. Usługa tokenu używa tych zasad do podpisywania tworzonych tokenów.
Gdy urządzenie lub moduł musi uzyskać dostęp do centrum IoT, żąda podpisanego tokenu z usługi tokenu. Urządzenie może uwierzytelniać się za pomocą niestandardowego rejestru tożsamości/schematu uwierzytelniania w celu określenia tożsamości urządzenia/modułu używanej przez usługę tokenu do utworzenia tokenu.
Usługa wydawania tokenów zwraca token. Token jest tworzony przy użyciu /devices/{deviceId} lub /devices/{deviceId}/modules/{moduleId} jako resourceURI, przy czym deviceId to urządzenie, które jest uwierzytelniane, a moduleId to moduł, który jest uwierzytelniany. Usługa tokenu używa zasad dostępu współdzielonego do konstruowania tokenu.
Urządzenie/moduł używa tokenu bezpośrednio z centrum IoT.

Uwaga

Możesz użyć klasy .NET SharedAccessSignatureBuilder lub klasy Java IotHubServiceSasToken , aby utworzyć token w usłudze tokenu.

Usługa tokenu może ustawić wygaśnięcie tokenu zgodnie z potrzebami. Po wygaśnięciu tokenu centrum IoT hub rozłącza połączenie urządzenia/modułu. Następnie urządzenie/moduł musi zażądać nowego tokenu z usługi tokenu. Krótki czas wygaśnięcia zwiększa obciążenie zarówno urządzenia/modułu, jak i usługi tokenu.

Aby urządzenie/moduł łączył się z centrum, należy nadal dodać go do rejestru tożsamości usługi IoT Hub, mimo że używa tokenu, a nie klucza do nawiązania połączenia. W związku z tym można nadal używać kontroli dostępu dla poszczególnych urządzeń/modułów, włączając lub wyłączając tożsamości urządzeń/modułów w rejestrze tożsamości. Takie podejście ogranicza ryzyko używania tokenów z długim czasem wygaśnięcia.

Porównanie z bramą niestandardową

Wzorzec usługi tokenu jest zalecanym sposobem implementacji niestandardowego rejestru tożsamości/schematu uwierzytelniania za pomocą usługi IoT Hub. Ten wzorzec jest zalecany, ponieważ usługa IoT Hub nadal obsługuje większość ruchu rozwiązania. Jeśli jednak niestandardowy schemat uwierzytelniania jest ściśle zintegrowany z protokołem, może wymagać przetworzenia całego ruchu przez niestandardową bramę. Przykładem takiego scenariusza jest użycie protokołu Transport Layer Security (TLS) i kluczy wstępnych (PSK). Aby uzyskać więcej informacji, zobacz How an IoT Edge device can be used as a gateway (Jak urządzenie usługi IoT Edge może być używane jako brama).

Generowanie tokenów SAS

Zestawy SDK usługi Azure IoT automatycznie generują tokeny, ale niektóre scenariusze wymagają generowania i bezpośredniego używania tokenów SAS, w tym:

Bezpośrednie użycie powierzchni MQTT, AMQP lub HTTPS.
Implementacja wzorca usługi tokenu, zgodnie z opisem w sekcji Tworzenie usługi tokenu w celu zintegrowania istniejących urządzeń .

Token podpisany przy użyciu klucza dostępu współdzielonego udziela dostępu do wszystkich funkcji skojarzonych z uprawnieniami zasad dostępu współdzielonego. Token podpisany przy użyciu klucza symetrycznego tożsamości urządzenia przyznaje uprawnienie DeviceConnect tylko dla skojarzonej tożsamości urządzenia.

Ta sekcja zawiera przykłady generowania tokenów SAS w różnych językach kodu. Tokeny SAS można również wygenerować za pomocą polecenia rozszerzenia CLI az iot hub generate-sas-token lub rozszerzenia usługi Azure IoT Hub dla programu Visual Studio Code.

Struktura tokenu SAS

Token SAS ma następujący format:

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

Oto oczekiwane wartości:

Wartość	Opis
{Zasób URI zakodowany w URL}	Kodowanie URL z małymi literami dla zasobu URI z małymi literami
{resourceURI}	Prefiks identyfikatora URI (według segmentu) punktów końcowych, do których można uzyskać dostęp za pomocą tego tokenu, rozpoczynając od nazwy hosta centrum IoT (bez protokołu). Tokeny SAS przyznane usługom zaplecza są ograniczone do poziomu IoT Hub; na przykład `myHub.azure-devices.net`. Tokeny SAS przyznane urządzeniom muszą być ograniczone do poszczególnych urządzeń; na przykład `myHub.azure-devices.net/devices/device1`.
{signature-string}	Ciąg podpisu HMAC-SHA256 formularza: `{URL-encoded-resourceURI} + "\n" + {expiry}`. Ważne: klucz jest dekodowany z base64 i używany jako klucz do wykonywania obliczeń HMAC-SHA256.
{wygaśnięcie}	Ciągi UTF8 reprezentujące liczbę sekund od punktu początkowego 00:00:00 UTC 1 stycznia 1970 r.
{policyName}	Nazwa zasad dostępu współdzielonego, do których odwołuje się ten token. Nieobecny, jeśli token dotyczy poświadczeń rejestru urządzeń.

Prefiks identyfikatora URI jest obliczany według segmentu, a nie według znaku. Na przykład /a/b jest prefiksem dla /a/b/c, ale nie dla /a/bc.

Poniższy kod generuje token SAS przy użyciu identyfikatora URI zasobu, klucza podpisywania, nazwy zasad i okresu wygaśnięcia. W następnych sekcjach opisano sposób inicjowania różnych danych wejściowych dla różnych przypadków użycia tokenu.

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;
};

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)

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;
}

Poniższy kod generuje token SAS przy użyciu identyfikatora URI zasobu i klucza podpisywania. Okres wygaśnięcia jest ustawiony na jedną godzinę od bieżącego czasu. W następnych sekcjach opisano sposób inicjowania różnych danych wejściowych dla różnych przypadków użycia tokenu.

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;
}

Specyfika protokołu

Każdy obsługiwany protokół, taki jak MQTT, AMQP i HTTPS, transportuje tokeny na różne sposoby.

W przypadku korzystania z MQTT pakiet CONNECT ma identyfikator deviceId jako ClientId, {iothubhostname}/{deviceId} w polu Nazwa użytkownika i token SAS w polu Hasło. {iothubhostname} powinna być pełną nazwą CName centrum IoT, na przykład myhub.azure-devices.net.

W przypadku korzystania z protokołu AMQP usługa IoT Hub obsługuje SASL PLAIN i zabezpieczenia oparte na oświadczeniach AMQP.

Jeśli używasz zabezpieczeń opartych na oświadczeniach amQP, standard określa sposób przesyłania tych tokenów.

W przypadku pliku SASL PLAIN nazwa użytkownika może być:

{policyName}@sas.root.{iothubName} w przypadku korzystania z tokenów na poziomie centrum IoT.
{deviceId}@sas.{iothubname} jeśli używasz tokenów powiązanych z urządzeniem.

W obu przypadkach pole hasła zawiera token, zgodnie z opisem w strukturze tokenu SAS.

Protokół HTTPS implementuje uwierzytelnianie, dołączając prawidłowy token w nagłówku żądania autoryzacji .

Na przykład nazwa użytkownika (w polu DeviceId jest uwzględniana wielkość liter): iothubname.azure-devices.net/DeviceId

Hasło (token SAS można wygenerować za pomocą polecenia rozszerzenia interfejsu wiersza polecenia az iot hub generate-sas-token lub rozszerzenia usługi Azure IoT Hub dla programu Visual Studio Code):

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

Uwaga

Zestawy SDK usługi Azure IoT Hub automatycznie generują tokeny podczas nawiązywania połączenia z usługą. W niektórych przypadkach zestawy SDK usługi Azure IoT nie obsługują wszystkich protokołów ani wszystkich metod uwierzytelniania.

Uwagi specjalne dotyczące SASL PLAIN

W przypadku korzystania z protokołu SASL PLAIN z protokołem AMQP klient łączący się z centrum IoT może używać jednego tokenu dla każdego połączenia TCP. Po wygaśnięciu tokenu połączenie TCP rozłącza się z usługą i wyzwala ponowne połączenie. To zachowanie, chociaż nie jest problematyczne dla aplikacji zaplecza, jest szkodliwe dla aplikacji urządzenia z następujących powodów:

Bramy sieciowe zwykle łączą się w imieniu wielu urządzeń. W przypadku korzystania z protokołu SASL PLAIN muszą utworzyć odrębne połączenie TCP dla każdego urządzenia łączącego się z centrum IoT Hub. Ten scenariusz znacznie zwiększa zużycie energii i zasobów sieciowych oraz zwiększa opóźnienie każdego połączenia urządzenia.
Zwiększone wykorzystanie zasobów do ponownego nawiązania połączenia po wygaśnięciu każdego tokenu ma negatywny wpływ na urządzenia z ograniczonymi zasobami.

Następne kroki

Teraz, gdy wiesz, jak kontrolować dostęp do usługi IoT Hub, możesz zainteresować się następującymi artykułami w przewodniku dewelopera IoT Hub:

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-05

Udostępnij za pomocą

Kontrolowanie dostępu do usługi IoT Hub przy użyciu sygnatur dostępu współdzielonego

Uwierzytelnianie i autoryzacja

Kontrola dostępu i uprawnienia

Zasady dostępu współdzielonego na poziomie centrum IoT

Poświadczenia zabezpieczeń dla każdego urządzenia

Używanie tokenów SAS z usług

Używanie tokenów SAS z urządzeń

Używanie klucza symetrycznego w rejestrze tożsamości

Używanie zasad dostępu współdzielonego do uzyskiwania dostępu w imieniu urządzenia

Tworzenie usługi tokenu w celu zintegrowania istniejących urządzeń

Porównanie z bramą niestandardową

Generowanie tokenów SAS

Struktura tokenu SAS

Specyfika protokołu

Uwagi specjalne dotyczące SASL PLAIN

Następne kroki

Sprzężenie zwrotne

Dodatkowe zasoby