Udostępnij za pośrednictwem

Konfigurowanie uwierzytelniania brokera MQTT

  • Artykuł

Ważne

Usługa Azure IoT Operations Preview — włączona przez usługę Azure Arc jest obecnie dostępna w wersji zapoznawczej. Nie należy używać tego oprogramowania w wersji zapoznawczej w środowiskach produkcyjnych.

Po udostępnieniu ogólnie dostępnej wersji należy wdrożyć nową instalację operacji usługi Azure IoT. Nie będzie można uaktualnić instalacji w wersji zapoznawczej.

Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Broker MQTT obsługuje wiele metod uwierzytelniania dla klientów i można skonfigurować każdy odbiornik tak, aby miał własny system uwierzytelniania przy użyciu zasobów BrokerAuthentication . Aby uzyskać listę dostępnych ustawień, zobacz dokumentację interfejsu API uwierzytelniania brokera .

Następujące reguły dotyczą relacji między brokerlistener i BrokerAuthentication:

  • Każdy element BrokerListener może mieć wiele portów. Każdy port może być połączony z zasobem BrokerAuthentication .
  • Każdy brokerAuthentication może obsługiwać wiele metod uwierzytelniania jednocześnie.

Aby połączyć element BrokerListener z zasobem BrokerAuthentication , określ authenticationRef pole w ports ustawieniu zasobu BrokerListener. Aby dowiedzieć się więcej, zobacz Zasób BrokerListener.

Domyślny zasób BrokerAuthentication

Usługa Azure IoT Operations Preview wdraża domyślny zasób BrokerAuthentication o nazwie połączony z odbiornikiem domyślnym o nazwie authn listener w azure-iot-operations przestrzeni nazw. Jest ona skonfigurowana do używania tylko tokenów kont usługi Kubernetes Service do uwierzytelniania. Aby go sprawdzić, uruchom polecenie:

kubectl get brokerauthentication authn -n azure-iot-operations -o yaml

Dane wyjściowe zawierają domyślny zasób BrokerAuthentication z metadanymi usuniętymi w celu zwięzłości:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - "aio-internal"

Ważne

Metoda uwierzytelniania tokenu konta usługi (SAT) w domyślnym zasobie BrokerAuthentication jest wymagana do prawidłowego działania składników w operacjach usługi Azure IoT. Unikaj aktualizowania lub usuwania domyślnego zasobu BrokerAuthentication . Jeśli musisz wprowadzić zmiany, zmodyfikuj authenticationMethods pole w tym zasobie, zachowując metodę uwierzytelniania SAT z odbiorcami aio-internal . Najlepiej, aby utworzyć nowy zasób BrokerAuthentication o innej nazwie i wdrożyć go przy użyciu polecenia kubectl apply.

Aby zmienić konfigurację, zmodyfikuj authenticationMethods ustawienie w tym zasobie BrokerAuthentication lub utwórz nowy zasób BrokerAuthentication o innej nazwie. Następnie wdróż go przy użyciu polecenia kubectl apply.

Przepływ uwierzytelniania

Kolejność metod uwierzytelniania w tablicy określa, jak broker MQTT uwierzytelnia klientów. Broker MQTT próbuje uwierzytelnić poświadczenia klienta przy użyciu pierwszej określonej metody i iteruje przez tablicę do momentu znalezienia dopasowania lub osiągnięcia końca.

Dla każdej metody broker MQTT najpierw sprawdza, czy poświadczenia klienta są istotne dla tej metody. Na przykład uwierzytelnianie SAT wymaga nazwy użytkownika rozpoczynającej się od K8S-SAT, a uwierzytelnianie X.509 wymaga certyfikatu klienta. Jeśli poświadczenia klienta są istotne, broker MQTT sprawdza, czy są prawidłowe. Aby uzyskać więcej informacji, zobacz sekcję Konfigurowanie metody uwierzytelniania.

W przypadku uwierzytelniania niestandardowego broker MQTT traktuje błąd komunikacji z niestandardowym serwerem uwierzytelniania, ponieważ poświadczenia nie są istotne. To zachowanie umożliwia brokerowi MQTT powrót do innych metod, jeśli serwer niestandardowy jest niemożliwy do osiągnięcia.

Przepływ uwierzytelniania kończy się po:

  • Jeden z tych warunków jest spełniony:
    • Poświadczenia klienta są istotne i prawidłowe dla jednej z metod.
    • Poświadczenia klienta nie są istotne dla żadnej z metod.
    • Poświadczenia klienta są istotne, ale nieprawidłowe dla dowolnej z metod.
  • Broker MQTT udziela lub odmawia dostępu do klienta na podstawie wyniku przepływu uwierzytelniania.

W przypadku wielu metod uwierzytelniania broker MQTT ma mechanizm rezerwowy. Na przykład:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...
    - method: X509
      x509Settings:
        # ...

Wcześniejszy przykład określa niestandardowe i SAT. Gdy klient nawiąż połączenie, broker MQTT próbuje uwierzytelnić klienta przy użyciu określonych metod w podanej kolejności niestandardowej , a następnie SAT.

  1. Broker MQTT sprawdza, czy poświadczenia klienta są prawidłowe do uwierzytelniania niestandardowego. Ponieważ uwierzytelnianie niestandardowe opiera się na serwerze zewnętrznym w celu określenia ważności poświadczeń, broker uwzględnia wszystkie poświadczenia istotne dla niestandardowego uwierzytelniania i przekazuje je do niestandardowego serwera uwierzytelniania.

  2. Jeśli niestandardowy serwer uwierzytelniania odpowiada Pass na wartość lub Fail wynik, przepływ uwierzytelniania kończy się. Jeśli jednak niestandardowy serwer uwierzytelniania nie jest dostępny, broker MQTT powraca do pozostałych określonych metod, a serwer SAT jest następny.

  3. Broker MQTT próbuje uwierzytelnić poświadczenia jako poświadczenia SAT. Jeśli nazwa użytkownika MQTT rozpoczyna się od K8S-SAT, broker MQTT ocenia hasło MQTT jako sat.

Jeśli niestandardowy serwer uwierzytelniania jest niedostępny, a wszystkie kolejne metody ustaliły, że podane poświadczenia nie są istotne, broker odmawia połączenia klienta.

Wyłączanie uwierzytelniania

Na potrzeby testowania można wyłączyć uwierzytelnianie, pomijając authenticationRef ports ustawienie zasobu BrokerListener.

Konfigurowanie metody uwierzytelniania

Aby dowiedzieć się więcej o każdej z opcji uwierzytelniania, zobacz następne sekcje dla każdej metody.

Aby uzyskać więcej informacji na temat włączania bezpiecznych ustawień przez skonfigurowanie usługi Azure Key Vault i włączanie tożsamości obciążeń, zobacz Włączanie bezpiecznych ustawień we wdrożeniu usługi Azure IoT Operations Preview.

X.509

Aby zweryfikować certyfikat klienta, wymagany jest zaufany certyfikat głównego urzędu certyfikacji. Certyfikaty klienta muszą być zakorzenione w tym urzędzie certyfikacji dla brokera MQTT w celu ich uwierzytelnienia. Obsługiwane są zarówno klucze EC, jak i RSA, ale wszystkie certyfikaty w łańcuchu muszą używać tego samego algorytmu klucza. Jeśli importujesz własne certyfikaty urzędu certyfikacji, upewnij się, że certyfikat klienta używa tego samego algorytmu klucza co urzędy certyfikacji. Aby zaimportować certyfikat główny, który może służyć do weryfikowania certyfikatów klienta, zaimportuj certyfikat PEM jako ConfigMap pod kluczem client_ca.pem. Na przykład:

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

Aby sprawdzić, czy certyfikat głównego urzędu certyfikacji został prawidłowo zaimportowany, uruchom polecenie kubectl describe configmap. Wynik przedstawia to samo kodowanie base64 pliku certyfikatu PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

Po zaimportowaniu certyfikatu głównego urzędu certyfikacji zaufanego klienta i mapowania certyfikatu na atrybut włącz uwierzytelnianie klienta X.509, dodając go jako jedną z metod uwierzytelniania w ramach zasobu BrokerAuthentication połączonego z odbiornikiem obsługującym protokół TLS. Na przykład:

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
        # ...

Atrybuty certyfikatu do autoryzacji

Atrybuty X.509 można określić w zasobie BrokerAuthentication i są używane do autoryzowania klientów na podstawie ich właściwości certyfikatu. Atrybuty są zdefiniowane w authorizationAttributes polu. Na przykład:

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        authorizationAttributes:
          root:
            subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
            attributes:
              organization = contoso
          intermediate:
            subject = "CN = Contoso Intermediate CA"
            attributes:
              city = seattle
              foo = bar
          smart-fan:
            subject = "CN = smart-fan"
            attributes:
              building = 17

W tym przykładzie każdy klient z certyfikatem wystawionym przez główny urząd certyfikacji CN = Contoso Root CA Cert, OU = Engineering, C = US lub pośredni urząd certyfikacji CN = Contoso Intermediate CA otrzymuje wymienione atrybuty. Ponadto inteligentny wentylator otrzymuje atrybuty specyficzne dla niego.

Dopasowanie atrybutów zawsze rozpoczyna się od certyfikatu klienta liścia, a następnie przechodzi wzdłuż łańcucha. Przypisanie atrybutu zostaje zatrzymane po pierwszym dopasowaniu. W poprzednim przykładzie, nawet jeśli smart-fan ma certyfikat CN = Contoso Intermediate CApośredni , nie pobiera skojarzonych atrybutów.

Reguły autoryzacji można stosować do klientów przy użyciu certyfikatów X.509 z tymi atrybutami. Aby dowiedzieć się więcej, zobacz Autoryzowanie klientów korzystających z uwierzytelniania X.509.

Łączenie klienta mosquitto z brokerem MQTT przy użyciu certyfikatu klienta X.509

Klient, taki jak mosquitto, potrzebuje trzech plików, aby móc nawiązać połączenie z brokerem MQTT przy użyciu uwierzytelniania klienta TLS i X.509. Na przykład:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem

W przykładzie:

  • Parametr --cert określa plik PEM certyfikatu klienta.
  • Parametr --key określa plik PEM klucza prywatnego klienta.
  • Trzeci parametr --cafile jest najbardziej złożony: zaufana baza danych certyfikatów używana do dwóch celów:
    • Gdy klient mosquitto łączy się z brokerem MQTT za pośrednictwem protokołu TLS, weryfikuje certyfikat serwera. Wyszukuje certyfikaty główne w bazie danych, aby utworzyć zaufany łańcuch certyfikatu serwera. W związku z tym należy skopiować certyfikat główny serwera do tego pliku.
    • Gdy broker MQTT żąda certyfikatu klienta od klienta mosquitto, wymaga również prawidłowego łańcucha certyfikatów do wysłania na serwer. Parametr --cert informuje mosquitto, który certyfikat ma być wysyłany, ale nie wystarczy. Broker MQTT nie może zweryfikować tego certyfikatu samodzielnie, ponieważ wymaga również certyfikatu pośredniego. Mosquitto używa pliku bazy danych do utworzenia niezbędnego łańcucha certyfikatów. Aby to umożliwić, cafile musi zawierać zarówno certyfikaty pośrednie, jak i główne.

Omówienie przepływu uwierzytelniania klienta X.509 brokera MQTT

Diagram przepływu uwierzytelniania klienta X.509.

Poniżej przedstawiono kroki przepływu uwierzytelniania klienta:

  1. Gdy uwierzytelnianie klienta X.509 jest włączone, łączenie klientów musi przedstawić certyfikat klienta i wszystkie certyfikaty pośrednie, aby umożliwić brokerowi MQTT utworzenie łańcucha certyfikatów rooted do jednego ze skonfigurowanych zaufanych certyfikatów.
  2. Moduł równoważenia obciążenia kieruje komunikację z jednym z brokerów frontonu.
  3. Gdy broker frontonu odebrał certyfikat klienta, próbuje utworzyć łańcuch certyfikatów, który jest zakorzeniony w jednym ze skonfigurowanych certyfikatów. Certyfikat jest wymagany do uzgadniania protokołu TLS. Jeśli broker frontonu pomyślnie skompilował łańcuch, a przedstawiony łańcuch zostanie zweryfikowany, zakończy uzgadnianie protokołu TLS. Klient łączący może wysyłać pakiety MQTT do frontonu za pośrednictwem wbudowanego kanału TLS.
  4. Kanał TLS jest otwarty, ale uwierzytelnianie lub autoryzacja klienta nie zostało jeszcze zakończone.
  5. Następnie klient wysyła pakiet CONNECT do brokera MQTT.
  6. Pakiet CONNECT jest ponownie kierowany do frontonu.
  7. Fronton zbiera wszystkie poświadczenia przedstawione do tej pory przez klienta, takie jak pola nazwy użytkownika i hasła, dane uwierzytelniania z pakietu CONNECT oraz łańcuch certyfikatów klienta przedstawiony podczas uzgadniania protokołu TLS.
  8. Fronton wysyła te poświadczenia do usługi uwierzytelniania. Usługa uwierzytelniania ponownie sprawdza łańcuch certyfikatów i zbiera nazwy podmiotów wszystkich certyfikatów w łańcuchu.
  9. Usługa uwierzytelniania używa skonfigurowanych reguł autoryzacji, aby określić, jakie atrybuty ma łączących się klientów. Te atrybuty określają, jakie operacje może wykonać klient, w tym sam pakiet CONNECT.
  10. Usługa uwierzytelniania zwraca decyzję o brokerze frontonu.
  11. Broker frontonu zna atrybuty klienta i czy może nawiązać połączenie. Jeśli tak, połączenie MQTT zostanie ukończone, a klient będzie mógł nadal wysyłać i odbierać pakiety MQTT określone przez reguły autoryzacji.

Tokeny konta usługi Kubernetes Service

Tokeny konta usługi Kubernetes Service to tokeny internetowe JSON skojarzone z kontami usługi Kubernetes. Klienci przedstawiają usługi SATs brokerowi MQTT w celu uwierzytelnienia się.

Broker MQTT używa powiązanych tokenów konta usługi, które zostały szczegółowo opisane w wpisie Co użytkownicy GKE muszą wiedzieć o nowych tokenach konta usługi Kubernetes. Oto ważne funkcje z wpisu:

Uruchomiony na platformie Kubernetes 1.13 i staje się domyślnym formatem w wersji 1.21, powiązany tokeny dotyczą wszystkich ograniczonych funkcji starszych tokenów i nie tylko:

  • Same tokeny są trudniejsze do kradzieży i nieprawidłowego użycia; są one powiązane czasowo, powiązane z odbiorcami i powiązane z obiektem.
  • Przyjmują ustandaryzowany format: OpenID Connect (OIDC), z pełnym odnajdywaniem OIDC, co ułatwia dostawcom usług akceptowanie ich.
  • Są one bezpiecznie dystrybuowane do zasobników przy użyciu nowego typu woluminu przewidywanego przez kubelet.

Broker weryfikuje tokeny przy użyciu interfejsu API przeglądu tokenu platformy Kubernetes. Włącz funkcję Kubernetes TokenRequestProjection , aby określić audiences (wartość domyślna od wersji 1.21). Jeśli ta funkcja nie jest włączona, nie można jej używać.

Tworzenie konta usługowego

Aby utworzyć konta usługi, najpierw utwórz konto usługi. Następujące polecenie tworzy konto usługi o nazwie mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Dodawanie atrybutów autoryzacji

Uwierzytelnianie klientów za pośrednictwem sat może opcjonalnie mieć ich ATS adnotacje z atrybutami, które mają być używane z niestandardowymi zasadami autoryzacji. Aby dowiedzieć się więcej, zobacz Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes Service.

Włączanie uwierzytelniania tokenu konta usługi (SAT)

Zmodyfikuj authenticationMethods ustawienie w zasobie BrokerAuthentication , aby określić ServiceAccountToken jako prawidłową metodę uwierzytelniania. Określa audiences listę prawidłowych odbiorców tokenów. Wybierz unikatowe wartości identyfikujące usługę brokera MQTT. Musisz określić co najmniej jedną grupę odbiorców, a wszystkie grupy Zabezpieczeń muszą być zgodne z jedną z określonych grup odbiorców.

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - "aio-internal"
        - "my-audience"

Zastosuj zmiany za pomocą polecenia kubectl apply. Wprowadzenie zmian może potrwać kilka minut.

Testowanie uwierzytelniania SAT

Uwierzytelnianie SAT musi być używane z klienta w tym samym klastrze co broker MQTT. Dozwolone są tylko rozszerzone pola uwierzytelniania. Ustaw metodę uwierzytelniania na K8S-SAT wartość i dane uwierzytelniania na token.

Następujące polecenie określa zasobnik, który ma klienta mosquitto i instaluje sat utworzone w poprzednich krokach do zasobnika.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

serviceAccountName W tym miejscu pole w konfiguracji zasobnika musi być zgodne z kontem usługi skojarzonym z używanym tokenem. serviceAccountToken.audience Ponadto pole w konfiguracji zasobnika musi być jednym ze skonfigurowanych audiences w zasobie BrokerAuthentication.

Po utworzeniu zasobnika uruchom powłokę w zasobniku:

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

W powłoce zasobnika uruchom następujące polecenie, aby opublikować komunikat w brokerze:

mosquitto_pub --host aio-broker --port 18883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/mq-sat)

Dane wyjściowe powinny wyglądać mniej więcej tak:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

Klient mosquitto używa tokenu konta usługi zainstalowanego na stronie /var/run/secrets/tokens/mq-sat do uwierzytelniania za pomocą brokera. Token jest ważny przez 24 godziny. Klient używa również domyślnego certyfikatu głównego urzędu certyfikacji zainstalowanego pod adresem , /var/run/certs/ca.crt aby zweryfikować łańcuch certyfikatów TLS brokera.

Odświeżanie tokenów konta usługi

Tokeny konta usługi są ważne przez ograniczony czas i skonfigurowane za pomocą polecenia expirationSeconds. Jednak platforma Kubernetes automatycznie odświeża token przed jego wygaśnięciem. Token jest odświeżany w tle, a klient nie musi wykonywać żadnych czynności innych niż pobieranie go ponownie.

Jeśli na przykład klient jest zasobnikiem, który używa tokenu zainstalowanego jako wolumin, podobnie jak w przykładzie testowego uwierzytelniania SAT, najnowszy token jest dostępny w tej samej ścieżce /var/run/secrets/tokens/mqtt-client-token. Podczas nawiązywania nowego połączenia klient może pobrać najnowszy token i użyć go do uwierzytelniania. Klient powinien również mieć mechanizm obsługi nieautoryzowanych błędów MQTT przez pobranie najnowszego tokenu i ponowienie próby połączenia.

Uwierzytelnianie niestandardowe

Rozszerzanie uwierzytelniania klienta poza podane metody uwierzytelniania przy użyciu uwierzytelniania niestandardowego. Jest ona podłączona , ponieważ usługa może być niczym, o ile jest zgodna z interfejsem API.

Gdy klient łączy się z brokerem MQTT i jest włączone uwierzytelnianie niestandardowe, broker MQTT deleguje weryfikację poświadczeń klienta do niestandardowego serwera uwierzytelniania z żądaniem HTTP wraz ze wszystkimi poświadczeniami prezentowanymi przez klienta. Niestandardowy serwer uwierzytelniania odpowiada za zgodą lub odmową dla klienta przy użyciu atrybutów klienta na potrzeby autoryzacji.

Tworzenie niestandardowej usługi uwierzytelniania

Niestandardowy serwer uwierzytelniania jest implementowany i wdrażany oddzielnie od brokera MQTT.

Przykładowy niestandardowy serwer uwierzytelniania i instrukcje są dostępne w witrynie GitHub. Użyj tego przykładu jako szablonu i punktu wyjścia do implementowania własnej niestandardowej logiki uwierzytelniania.

interfejs API

Interfejs API między brokerem MQTT i niestandardowym serwerem uwierzytelniania jest zgodne ze specyfikacją interfejsu API na potrzeby uwierzytelniania niestandardowego. Specyfikacja interfejsu OpenAPI jest dostępna w witrynie GitHub.

Protokół HTTPS z szyfrowaniem TLS jest wymagany

Broker MQTT wysyła żądania zawierające poufne poświadczenia klienta do niestandardowego serwera uwierzytelniania. Aby chronić te poświadczenia, komunikacja między brokerem MQTT i niestandardowym serwerem uwierzytelniania musi być szyfrowana przy użyciu protokołu TLS.

Niestandardowy serwer uwierzytelniania musi przedstawić certyfikat serwera, a broker MQTT musi mieć zaufany certyfikat głównego urzędu certyfikacji do weryfikacji certyfikatu serwera. Opcjonalnie niestandardowy serwer uwierzytelniania może wymagać od brokera MQTT przedstawienia certyfikatu klienta w celu uwierzytelnienia się.

Włączanie uwierzytelniania niestandardowego dla odbiornika

Zmodyfikuj authenticationMethods ustawienie w zasobie BrokerAuthentication , aby określić Custom jako prawidłową metodę uwierzytelniania. Następnie określ parametry wymagane do komunikowania się z niestandardowym serwerem uwierzytelniania.

W tym przykładzie przedstawiono wszystkie możliwe parametry. Dokładne wymagane parametry zależą od wymagań poszczególnych serwerów niestandardowych.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretName: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Rozłączanie klienta po wygaśnięciu poświadczeń

Broker MQTT rozłącza klientów po wygaśnięciu poświadczeń. Rozłącz po wygaśnięciu poświadczeń dotyczy wszystkich klientów łączących się z frontonami brokera MQTT, w tym:

  • Klienci uwierzytelnieni przy użyciu protokołu SAT rozłączają się po wygaśnięciu ich sat
  • Klienci uwierzytelnieni za pomocą protokołu X.509 rozłączają się po wygaśnięciu certyfikatu klienta
  • Klienci uwierzytelnieni za pomocą niestandardowego uwierzytelniania rozłączają się na podstawie czasu wygaśnięcia zwróconego z niestandardowego serwera uwierzytelniania.

Po rozłączeniu połączenie sieciowe klienta jest zamknięte. Klient nie otrzyma pakietu MQTT DISCONNECT, ale broker rejestruje komunikat, że odłączył klienta.

Klienci MQTT w wersji 5 uwierzytelnieni za pomocą protokołów SAT i uwierzytelniania niestandardowego mogą ponownie uwierzytelniać się przy użyciu nowego poświadczenia przed wygaśnięciem ich początkowych poświadczeń. Klienci X.509 nie mogą ponownie uwierzytelniać się i muszą ponownie ustanowić połączenie, ponieważ uwierzytelnianie odbywa się w warstwie TLS.

Klienci mogą ponownie uwierzytelniać się, wysyłając pakiet UWIERZYTELNIANIA MQTT v5.

Klienci SAT wysyłają klienta UWIERZYTELNIANIA przy użyciu pól method: K8S-SAT, data: <token>. Klienci uwierzytelniania niestandardowego ustawiają metodę i pole danych zgodnie z wymaganiami niestandardowego serwera uwierzytelniania.

Pomyślne ponowne uwierzytelnienie aktualizuje wygasanie poświadczeń klienta z upływem czasu wygaśnięcia nowego poświadczenia, a broker odpowiada za pomocą pakietu Success AUTH . Uwierzytelnianie nie powiodło się z powodu przejściowych problemów, co spowodowało, że broker odpowiedział przy użyciu pakietu AUTH ContinueAuthentication. Na przykład niestandardowy serwer uwierzytelniania jest niedostępny. Klient może spróbować ponownie później. Inne błędy uwierzytelniania powodują, że broker wysyła pakiet DISCONNECT i zamyka połączenie sieciowe klienta.

Powiązana zawartość