Konfigurowanie autoryzacji brokera MQTT

Ważne

Ta strona zawiera instrukcje dotyczące zarządzania składnikami operacji usługi Azure IoT przy użyciu manifestów wdrażania platformy Kubernetes, które są w wersji zapoznawczej. Ta funkcja jest udostępniana z kilkoma ograniczeniami i nie powinna być używana w przypadku obciążeń produkcyjnych.

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.

Zasady autoryzacji określają, jakie akcje mogą wykonywać klienci na brokerze, takie jak łączenie, publikowanie lub subskrybowanie tematów. Skonfiguruj brokerA MQTT tak, aby używał jednego lub wielu zasad autoryzacji za pomocą zasobu BrokerAuthorization. Każdy zasób BrokerAuthorization zawiera listę reguł określających podmioty zabezpieczeń i zasoby zasad autoryzacji.

Łączenie elementu BrokerAuthorization z elementem BrokerListener

Aby połączyć zasób BrokerListener z zasobem BrokerAuthorization, określ authorizationRef pole w ports ustawieniu zasobu BrokerListener. Podobnie jak w przypadku brokeraAuthentication, zasób BrokerAuthorization może być połączony z wieloma portami BrokerListener. Zasady autoryzacji dotyczą wszystkich połączonych portów odbiornika. Istnieje jedna kluczowa różnica w porównaniu z elementem BrokerAuthentication:

Ważne

Aby konfiguracja BrokerAuthorization miała zastosowanie do portu odbiornika, co najmniej jeden zasób BrokerAuthentication musi być również połączony z tym portem odbiornika.

Aby dowiedzieć się więcej o brokerlistener, zobacz Zasób BrokerListener.

Reguły autoryzacji

Aby skonfigurować autoryzację, utwórz zasób BrokerAuthorization w klastrze Kubernetes. W poniższych sekcjach przedstawiono przykłady konfigurowania autoryzacji dla klientów korzystających z nazw użytkowników, atrybutów, certyfikatów X.509 i tokenów kont usługi Kubernetes (SATs). Aby uzyskać listę dostępnych ustawień, zobacz dokumentację interfejsu API autoryzacji brokera .

W poniższym przykładzie pokazano, jak utworzyć zasób BrokerAuthorization przy użyciu nazw użytkowników i atrybutów.

Portal

1. W witrynie Azure Portal przejdź do wystąpienia operacji IoT.

2. W obszarze Składniki wybierz pozycję Broker MQTT.

3. Wybierz kartę Autoryzacja.

4. Wybierz istniejące zasady uwierzytelniania lub utwórz nowe, wybierając pozycję Utwórz zasady autoryzacji.

   

Bicep

Aby edytować zasady autoryzacji, utwórz .bicep plik z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            clientIds: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/telemetry/{principal.clientId}'
                '/telemetry/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          clientIds:
            - "temperature-sensor"
            - "humidity-sensor"
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.clientId}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Aby utworzyć ten zasób BrokerAuthorization, zastosuj manifest YAML do klastra Kubernetes.

Ta autoryzacja brokera umożliwia klientom z identyfikatorami temperature-sensor klienta lub humidity-sensor, lub klientów z atrybutami organization, z wartościami contoso i city, i z wartością seattle, do:

• Nawiąż połączenie z brokerem.
• Publikowanie komunikatów w tematach telemetrii o określonym zakresie przy użyciu identyfikatorów klientów i organizacji. Na przykład: .
  • temperature-sensor program może publikować w plikach /telemetry/temperature-sensor i /telemetry/contoso.
  • humidity-sensor program może publikować w plikach /telemetry/humidity-sensor i /telemetry/contoso.
  • some-other-username program może publikować w programie /telemetry/contoso.
• /commands/ Subskrybuj tematy objęte zakresem swojej organizacji. Na przykład: .
  • temperature-sensor program może subskrybować usługę /commands/contoso.
  • some-other-username program może subskrybować usługę /commands/contoso.

Używanie nazwy użytkownika do autoryzacji

Aby użyć nazwy użytkownika MQTT do autoryzacji, określ je jako tablicę w obszarze principals.usernames. W zależności od metody uwierzytelniania nazwa użytkownika może nie zostać zweryfikowana:

• Kubernetes SAT: Nazwa użytkownika nie powinna być używana do autoryzacji, ponieważ nie jest weryfikowana pod kątem MQTTv5 z rozszerzonym uwierzytelnianiem.
• X.509: Nazwa użytkownika jest zgodna z nazwą pospolitą (CN) z certyfikatu i może służyć do reguł autoryzacji.
• Niestandardowe: nazwa użytkownika powinna być używana tylko dla reguł autoryzacji, jeśli uwierzytelnianie niestandardowe weryfikuje nazwę użytkownika.

Aby zapobiec problemom z zabezpieczeniami, użyj nazwy użytkownika MQTT do autoryzacji brokera tylko wtedy, gdy można go zweryfikować.

Dalsze ograniczanie dostępu na podstawie identyfikatora klienta

principals Ponieważ pole jest logiczneOR, można dodatkowo ograniczyć dostęp na podstawie identyfikatorów klientów, dodając clientIds pole do brokerResources pola. Aby na przykład zezwolić klientom z identyfikatorami klientów rozpoczynającymi się od numeru kompilacji w celu nawiązania połączenia i opublikowania danych telemetrycznych w tematach o określonym zakresie w budynku, użyj następującej konfiguracji:

Portal

W regułach autoryzacji brokera dla zasad autoryzacji użyj następującej konfiguracji:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz .bicep plik z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            attributes: [
              {
                building: 'building22'
              }
              {
                building: 'building23'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
              clientIds: [
                '{principal.attributes.building}*' // client IDs must start with building22
              ]
            }
            {
              method: 'Publish'
              topics: [
                'sensors/{principal.attributes.building}/{principal.clientId}/telemetry'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
    - principals:
        attributes:
          - building: "building22"
          - building: "building23"
      brokerResources:
      - method: Connect
        clientIds:
          - "{principal.attributes.building}*" # client IDs must start with building22
      - method: Publish
        topics:
          - "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"

W tym miejscu, jeśli parametr clientIds nie został ustawiony w metodzie Connect , klient z dowolnym identyfikatorem klienta może nawiązać połączenie, building o ile atrybut ma ustawiony na building22 wartość lub building23. Po dodaniu clientIds pola tylko klienci z identyfikatorami klientów rozpoczynającymi się od building22 lub building23 mogą się łączyć. To oznaczenie gwarantuje, że klient ma prawidłowy atrybut i że identyfikator klienta jest zgodny z oczekiwanym wzorcem.

Autoryzowanie klientów korzystających z uwierzytelniania X.509

Można autoryzować klientów korzystających z certyfikatów X.509 do uwierzytelniania w celu uzyskania dostępu do zasobów na podstawie właściwości X.509 znajdujących się na ich certyfikacie lub certyfikatów wystawiających łańcuch.

Używanie atrybutów

Aby utworzyć reguły na podstawie właściwości na podstawie certyfikatu klienta, jego głównego urzędu certyfikacji lub pośredniego urzędu certyfikacji, zdefiniuj atrybuty X.509 w zasobie BrokerAuthorization. Aby uzyskać więcej informacji, zobacz Atrybuty certyfikatu.

W przypadku nazwy pospolitej podmiotu certyfikatu klienta jako nazwy użytkownika

Aby utworzyć zasady autoryzacji na podstawie tylko nazwy CN podmiotu certyfikatu klienta , utwórz reguły na podstawie nazwy CN.

Jeśli na przykład klient ma certyfikat z tematem CN = smart-lock, jego nazwa użytkownika to smart-lock. Z tego miejsca utwórz zasady autoryzacji w zwykły sposób.

Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes

Atrybuty autoryzacji dla sieci SAN są ustawiane jako część adnotacji konta usługi. Aby na przykład dodać atrybut autoryzacji o nazwie group z wartością authz-sat, uruchom polecenie :

kubectl annotate serviceaccount mqtt-client aio-broker-auth/group=authz-sat

Adnotacje atrybutów muszą zaczynać się od aio-broker-auth/ , aby odróżnić je od innych adnotacji.

Ponieważ aplikacja ma atrybut autoryzacji o nazwie authz-sat, nie ma potrzeby podawania clientId wartości lub username . Odpowiedni zasób BrokerAuthorization używa tego atrybutu jako podmiotu zabezpieczeń, na przykład:

Portal

W regułach autoryzacji brokera dla zasad autoryzacji użyj następującej konfiguracji:

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz .bicep plik z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      rules: [
        {
          principals: {
            attributes: [
              {
                group: 'authz-sat'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                'odd-numbered-orders'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                'orders'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Aby dowiedzieć się więcej na przykładzie, zobacz Konfigurowanie zasad autoryzacji za pomocą klienta dapr.

Magazyn stanów

Broker MQTT udostępnia magazyn stanów, którego klienci mogą używać do przechowywania stanu. Magazyn stanów można również skonfigurować tak, aby był wysoce dostępny.

Aby skonfigurować autoryzację dla klientów korzystających z magazynu stanów, podaj następujące uprawnienia:

• Uprawnienie do publikowania w temacie magazynu $services/statestore/_any_/command/invoke/request wartości klucza systemu
• Uprawnienie do subskrybowania tematu odpowiedzi (ustawionego podczas początkowego publikowania jako parametru) <response_topic>/#

Klucze magazynu stanów

Dostęp do magazynu stanów jest uzyskiwany za pośrednictwem brokera MQTT w temacie statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Ponieważ klienci mają dostęp do tematu, można określić klucze i poziomy dostępu w stateStoreResources sekcji konfiguracji brokera brokerResources MQTT.

Format stateStoreResources sekcji składa się z poziomu dostępu, wskaźnika wzorca i wzorca.

Portal

Uwzględnij sekcję stateStoreResources w regułach zasad autoryzacji.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Bicep

W aplikacji Bicep dołącz sekcję stateStoreResources w zasadach autoryzacji.

stateStoreResources: [
  {
    method: '' // Values: read, write, readwrite 
    keyType: '' //Values: string, pattern, binary. Default is pattern
    keys: [
      // List of patterns to match
    ]
  }
  {
    method: 'ReadWrite'
    keyType: 'Binary'
    keys: [
      'xxxxxxxxxxxxxxxxxxxx'
    ]
  }
]

Kubernetes

W definicji zasobu niestandardowego uwzględnij sekcję stateStoreResources w zasadach autoryzacji.

stateStoreResources:
  - method:  # Values: read, write, readwrite 
    keyType: # Values: string, pattern, binary. Default is pattern
    keys:
      - # List of patterns to match

Pole method określa poziom dostępu:

• Dostęp do odczytu jest określony za pomocą polecenia read. Dostęp do zapisu jest określony za pomocą polecenia write. Dostęp do odczytu i zapisu jest określony za pomocą polecenia readwrite.
• Wymagany jest poziom dostępu.
• Poziom dostępu do odczytu oznacza akcje i getkeynotify.
• Poziom dostępu do zapisu oznacza akcje set, deli vdel.

Pole keyType określa typ dopasowania klucza:

• pattern: służy do dopasowywania wzorców w stylu globu.
• string: Służy do dokładnego dopasowania, na przykład, gdy klucz zawiera znaki, które mogą być inaczej dopasowane jako wzorzec (*, ?, [0-9]).
• binary: służy do dopasowywania klucza binarnego.

Pole keys określa klucze, które mają być zgodne. Klucze można określić jako wzorce w stylu globu, podstawianie tokenów lub dokładne ciągi.

• Przykłady stylu globu:

  • colors/*: Wszystkie klucze pod prefiksem "kolory/"
  • number[0-9]: Dowolny klucz z "number0" do "number9"
  • char?: dowolny klucz z prefiksem "char" i sufiksem pojedynczej cyfry, na przykład "charA"
  • *: Pełny dostęp do wszystkich kluczy

• Klucze magazynu stanów obsługują również podstawianie tokenów, gdy typ klucza to pattern i nawiasy klamrowe są zarezerwowane do tego celu. Przykłady podstawiania tokenów:

  • clients/{principal.clientId}/*
  • usernames/{principal.username}/*
  • rooms/{principal.attributes.room}/*

Oto przykład tworzenia zasobów magazynu stanów.

Portal

W regułach autoryzacji brokera dla zasad autoryzacji dodaj podobną konfigurację:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry/*"
        ]
      },
      {
        "method": "Subscribe",
        "topics": [
          "commands/{principal.attributes.organization}"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "17",
          "organization": "contoso"
        }
      ],
      "usernames": [
        "temperature-sensor",
        "humidity-sensor"
      ]
    },
    "stateStoreResources": [
      {
        "method": "Read",
        "keyType": "Pattern",
        "keys": [
          "myreadkey",
          "myotherkey?",
          "mynumerickeysuffix[0-9]",
          "clients/{principal.clientId}/*"
        ]
      },
      {
        "method": "ReadWrite",
        "keyType": "Binary",
        "keys": [
          "xxxxxxxxxxxxxxxxxxxx"
        ]
      }
    ]
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz .bicep plik z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            usernames: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/telemetry/{principal.username}'
                '/telemetry/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
          stateStoreResources: [
            {
              method: 'Read'
              keyType: 'Pattern'
              keys: [
                'myreadkey'
                'myotherkey?'
                'mynumerickeysuffix[0-9]'
                'clients/{principal.clientId}/*'
              ]
            }
            {
              method: 'ReadWrite'
              keyType: 'Binary'
              keys: [
                'xxxxxxxxxxxxxxxxxxxx'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes

stateStoreResources:
  - method: Read # Read includes Get, Notify
    keyType: "pattern" # string, pattern, binary
    keys:
      - "myreadkey" # explicit read access on key: myreadkey
      - "myotherkey?" # single digit wildcard
      - "mynumerickeysuffix[0-9]" # single digit number range
      - "clients/{principal.clientId}/*" # use token substitution and a wildcard for per-client sandboxing
  - method: ReadWrite  # ReadWrite access includes Get, Notify, Set, Del
    keyType: "binary" # binary keys have exact match, no patterns
    keys:
      - "xxxxxxxxxxxxxxxxxxxx"  # base-64 encoded binary key.

Aktualizowanie autoryzacji

Zasoby autoryzacji brokera można aktualizować w czasie wykonywania bez ponownego uruchamiania. Wszyscy klienci połączeni w momencie aktualizacji zasad są rozłączone. Zmiana typu zasad jest również obsługiwana.

kubectl edit brokerauthorization my-authz-policies

Wyłączanie autoryzacji

Portal

1. W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
2. W obszarze Składniki wybierz pozycję Broker MQTT.
3. Wybierz odbiornik brokera, który chcesz edytować z listy.
4. Na porcie, na którym chcesz wyłączyć autoryzację, wybierz pozycję Brak z listy rozwijanej autoryzacji.

Bicep

Aby wyłączyć autoryzację, pomiń authorizationRefports ustawienie zasobu BrokerListener.

Kubernetes (wersja zapoznawcza)

Aby wyłączyć autoryzację, pomiń authorizationRefports ustawienie zasobu BrokerListener.

Nieautoryzowane publikowanie w MQTT 3.1.1

W przypadku protokołu MQTT 3.1.1 po odmowie publikowania klient otrzymuje kod PUBACK bez błędu, ponieważ wersja protokołu nie obsługuje zwracania kodu błędu. Funkcja MQTTv5 zwraca kod PUBACK z kodem przyczyny 135 (nieautoryzowanym) podczas odmowy publikowania.

Powiązana zawartość

• Zasób BrokerListener
• Konfigurowanie uwierzytelniania dla elementu BrokerListener
• Samouczek: uwierzytelnianie klienta TLS, X.509 i autoryzacja kontroli dostępu opartej na atrybutach (ABAC)