共用方式為

設定 MQTT 代理程式驗證

重要事項

此頁面包含使用 Kubernetes 部署資訊清單 (其處於預覽) 來管理 Azure IoT 操作元件的指示。 此功能的提供具有數項限制，因此不應用於生產工作負載。

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

MQTT 代理程式針對用戶端支援多個驗證方法。 您可以將每個接聽程式連接埠設定為與 BrokerAuthentication 資源具有自己的驗證設定。 如需可用設定的清單，請參閱代理程式驗證 API 參考。

下列規則適用 BrokerListener 與 BrokerAuthentication 資源之間的關聯性：

  • 每個 BrokerListener 資源可以有多個連接埠。 您可以將每個連接埠連結至 BrokerAuthentication 資源。
  • 每個 BrokerAuthentication 資源都可以一次支援多個驗證方法。
  • 未連結 BrokerAuthentication 資源的連接埠已停用驗證。

若要將 BrokerListener 連接埠連結至 BrokerAuthentication 資源，請在 BrokerListener 資源的 authenticationRef 設定中指定 ports 欄位。 若要深入了解，請參閱 BrokerListener 資源。

預設 BrokerAuthentication 資源

Azure IoT 操作會部署名為 default 的預設 BrokerAuthentication 資源，其會與 命名空間中的azure-iot-operations接聽程式連結。 它只會使用 Kubernetes 服務帳戶權杖 (SAT) 進行驗證。

重要事項

需要預設 BrokerAuthentication 資源中的 SAT 驗證方法，IoT 操作中的元件才能正常運作。 避免更新或刪除預設 BrokerAuthentication 資源。

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。

  2. 在 [元件] 底下，選取 [MQTT 代理程式]。

  3. 選取 [驗證] 索引標籤。

  4. 從驗證原則清單中，選取 [預設] 原則名稱。

    顯示使用 Azure 入口網站來檢視預設 MQTT 代理程式驗證原則的螢幕擷取畫面。

若要新增驗證方法，請選取 [新增方法]。

驗證流程

指定驗證方法的順序會決定 MQTT 代理程式如何驗證用戶端。 MQTT 代理程式會嘗試使用第一個指定的方法來驗證用戶端的認證，並逐一查看指定的方法，直到找到相符項目或到達結尾為止。

針對每個方法，MQTT 代理程式會先檢查用戶端的認證是否與該方法相關。 例如，SAT 驗證需要以 K8S-SAT 開頭的使用者名稱，而 X.509 驗證需要用戶端憑證。 如果用戶端的認證相關，MQTT 代理程式會驗證其是否有效。 如需詳細資訊，請參閱設定驗證方法一節。

針對自訂驗證，MQTT 代理程式會將與自訂驗證伺服器的通訊失敗視為認證不相關。 如果自訂驗證伺服器無法連線，此行為可讓 MQTT 代理程式後援至其他方法。

驗證流程在下列狀況下結束：

  • 其中一個條件為 True:
    • 用戶端的認證與其中一種方法相關且有效。
    • 用戶端的認證與任何方法無關。
    • 用戶端的認證與其中一種方法相關但無效。
  • MQTT 代理程式會根據驗證流程的結果，授與或拒絕對用戶端的存取權。

例如：

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

先前的範例會指定 custom 和 SAT。 當用戶端連線時，MQTT 代理程式會嘗試使用指定的方法來驗證用戶端，依照順序 custom 然後是 SAT。

  1. MQTT 代理程式會檢查用戶端的認證對自訂驗證是否有效。 由於自訂驗證仰賴外部伺服器來判斷認證的有效性，代理程式會考慮與自訂驗證相關的所有認證，並將其轉送至自訂驗證伺服器。
  2. 如果自訂驗證伺服器回應 Pass 或 Fail 結果，驗證流程就會結束。 如果自訂驗證伺服器無法使用，則 MQTT 代理程式會後援為其餘的指定方法，而 SAT 則為下一個。
  3. MQTT 代理程式會嘗試將認證驗證為 SAT 認證。

如果自訂驗證伺服器無法使用，且所有後續方法都判斷所提供的認證不相關，則代理程式會拒絕用戶端連線。

設定驗證方法

您可以新增驗證方法，例如 X.509、SAT 或自訂至驗證原則。

若要將驗證方法新增至原則：

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。

  2. 在 [元件] 底下，選取 [MQTT 代理程式]。

  3. 選取 [驗證] 索引標籤。

  4. 選擇現有的驗證原則或建立新的驗證原則。

  5. 選取 [新增方法] 以新增方法。

  6. 從下拉式清單中選擇方法類型，然後選取 [新增詳細資料] 以設定方法。

    顯示使用 Azure 入口網站新增 MQTT 代理程式驗證原則方法的螢幕擷取畫面。

若要深入了解每個驗證選項，請參閱每個方法的以下各節。

如需如何透過設定 Azure Key Vault 執行個體和啟用工作負載身分識別來啟用安全設定的詳細資訊，請參閱在 Azure IoT 操作部署中啟用安全設定。

X.509

秘訣

如需如何設定 X.509 驗證的端對端範例，請參閱教學課程：TLS、X.509 用戶端驗證和屬性型存取控制 (ABAC) 授權。

透過 X.509 驗證，MQTT 代理程式會使用受信任的憑證授權單位 (CA) 憑證來驗證用戶端憑證。 此信任的 CA 可以是根或中繼 CA。 代理程式會針對受信任的 CA 憑證檢查用戶端憑證鏈結。 如果鏈結有效，則會驗證用戶端。

若要搭配受信任的 CA 憑證使用 X.509 驗證，您必須符合下列需求：

  • 傳輸層安全性 (TLS) 通訊協定：因為 X.509 依賴 TLS 用戶端憑證，必須使用 X.509 驗證為連接埠啟用 TLS。
  • 金鑰演算法：支援 EC 和 RSA 金鑰，但鏈結中的所有憑證都必須使用相同的金鑰演算法。
  • 格式：CA 憑證必須是隱私權增強式郵件 (PEM) 格式。

秘訣

PEM 格式是憑證和金鑰的常見格式。 PEM 檔案是以 Base64 編碼的 ASCII 檔案，具有 -----BEGIN CERTIFICATE----- 和 -----BEGIN EC PRIVATE KEY----- 等標頭。

如果您擁有的是其他格式的憑證，則可以使用 OpenSSL 將其轉換成 PEM。 如需詳細資訊，請參閱將憑證轉換成適當的格式。

取得受信任的 CA 憑證

在生產設定中，CA 憑證是由組織的公開金鑰基礎結構 (PKI) 或公用憑證授權單位提供。

若要進行測試，請使用 OpenSSL 建立自我簽署的 CA 憑證。 例如，執行下列命令來產生具有 RSA 金鑰、辨別名稱 CN=Contoso Root CA Cert，以及有效期限為 365 天的自我簽署 CA 憑證：

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

與步驟 CLI 的相同命令，用於管理憑證的便利工具是：

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

這些命令會以 PEM 格式建立 CA 憑證 ca.pem 和私密金鑰 ca-key.pem。 您可以將 CA 憑證 ca.pem 匯入 MQTT 代理程式以進行 X.509 驗證。

匯入受信任的 CA 憑證

若要開始使用 X.509 驗證，請將受信任的 CA 憑證匯入 azure-iot-operations 命名空間中的 ConfigMap。 若要將受信任的 CA 憑證 ca.pem 匯入名為 client-ca 的 ConfigMap，請執行：

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

在此範例中，CA 憑證會匯入在金鑰 ca.pem 底下。 MQTT 代理程式會信任 ConfigMap 中的所有 CA 憑證，因此您可以使用任何項目做為金鑰的名稱。

若要檢查根 CA 憑證是否已正確匯入，請執行 kubectl describe configmap。 結果會顯示 PEM 憑證檔案的相同 Base64 編碼方式。

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

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

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

設定 X.509 驗證方法

匯入受信任的 CA 憑證之後，請啟用 X.509 用戶端驗證，方法是在 BrokerAuthentication 資源中將它新增為驗證方法。 確保此資源已連結至已啟用 TLS 的接聽程式連接埠。

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。

  2. 在 [元件] 底下，選取 [MQTT 代理程式]。

  3. 選取 [驗證] 索引標籤。

  4. 選擇現有的驗證原則或建立新的驗證原則。

  5. 選取 [新增方法] 以新增方法。

  6. 從下拉式清單中選擇 X.509 方法。 然後選取 [新增詳細資料] 以設定 方法。

  7. 在 [X.509 驗證詳細資料] 窗格中，使用 JSON 格式指定受信任的 CA 憑證 ConfigMap 名稱。

    {
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}

    將 <TRUSTED_CA_CONFIGMAP> 取代為包含受信任 CA 憑證的 ConfigMap 的名稱。 例如，使用 "trustedClientCaCert": "client-ca"。

    顯示使用 Azure 入口網站來設定 MQTT 代理程式 X.509 驗證方法的螢幕擷取畫面。

  8. 或者，使用 X.509 憑證新增用戶端的授權屬性。 若要深入了解，請參閱授權的憑證屬性。

  9. 選取 [套用] 以儲存變更。

選用：授權的憑證屬性

您可以在 BrokerAuthentication 資源中指定 X.509 屬性，以根據用戶端的憑證屬性來授權用戶端。 屬性會於 authorizationAttributes 欄位中定義。

例如：

在 Azure 入口網站中，當您設定 X.509 驗證方法時，請以 JSON 格式在 [X.509 驗證詳細資料] 窗格中新增授權屬性。

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "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"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

在此範例中，具有的憑證是由根 CA 簽發且辨別名稱為 CN = Contoso Root CA Cert, OU = Engineering, C = US 的每個用戶端，或具有辨別名稱 CN = Contoso Intermediate CA 的中繼 CA ，會接收列出的屬性。 此外，智慧型風扇用戶端憑證會接收其專屬的屬性。

屬性的比對一律從分葉用戶端憑證開始，然後沿著鏈結進行。 屬性指派會在最初相符項目之後停止。 在上一個範例中，即使 smart-fan 有中繼憑證 CN = Contoso Intermediate CA，它也不會取得相關聯的屬性。

您可以使用 X.509 憑證搭配這些屬性，將授權規則套用至用戶端。 若要深入了解，請參閱授權使用 X.509 驗證的用戶端。

選用：X.509 驗證的 Azure 裝置登錄檔整合 (預覽)

重要事項

X.509 驗證的 Azure 裝置登錄檔整合目前處於預覽。 此功能受限於某些限制，因此不建議用於生產工作負載。 如需詳細資訊，請參閱 Microsoft Azure 預覽版增補使用條款。

您可以啟用 Azure 裝置登錄檔與 X.509 驗證的整合，以強制執行裝置層級的憑證驗證和撤銷。 啟用時，此功能會要求 X.509 用戶端在裝置登錄中有相符的裝置，並可讓您停用對應的裝置來停用用戶端。

啟用 Azure 裝置登錄檔整合時：

  • 用戶端憑證必須具有符合 Azure 裝置登錄檔中裝置名稱的通用名稱 (CN)。
  • 只有已在登錄中啟用的裝置才能成功驗證。
  • 在用戶端驗證時會檢查裝置狀態，之後每隔 10 分鐘檢查一次。
  • 已停用或移除的裝置會被自動拒絕存取。

啟用此功能之前，請在 Azure 裝置登錄檔中為每個用戶端憑證建立對應的裝置。 裝置名稱必須符合憑證的一般名稱 (CN)。 若要在 Azure 裝置登錄檔中建立和管理裝置，請參閱：

若要啟用 Azure 裝置登錄檔整合，請在 X.509 設定中將 additionalValidation 欄位設定為 AzureDeviceRegistry。 additionalValidation 欄位會使用指定的方法執行用戶端憑證的其他驗證，且其支援的值為 AzureDeviceRegistry 或 None (預設值)：

在 Azure 入口網站中，當您設定 X.509 驗證方法時，請以 JSON 格式在 [X.509 驗證詳細資料] 窗格中新增 Azure 裝置登錄檔驗證：

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "additionalValidation": "AzureDeviceRegistry"
}

啟用 Azure 裝置登錄檔整合之後，請在 Azure 裝置登錄檔中為每個用戶端憑證建立對應的裝置。 裝置名稱必須符合憑證的一般名稱 (CN)。 如果用戶端嘗試使用在登錄中未啟用相符裝置的憑證進行驗證，則驗證會失敗。

啟用接聽程式連接埠的 X.509 驗證

匯入受信任的 CA 憑證並設定 BrokerAuthentication 資源之後，請將它連結至已啟用 TLS 的接聽程式連接埠。 此步驟很重要，因為 X.509 驗證依賴 TLS 進行用戶端憑證驗證。

若要取得已啟用 TLS 的接聽程式連接埠，請參閱啟用連接埠的 TLS 手動憑證管理和啟用連接埠的 TLS 自動憑證管理。

附註

在代理程式接聽程式連接埠上啟用 TLS 表示代理程式使用伺服器憑證進行 TLS 加密。 當用戶端連線到此連接埠時，它們必須信任伺服器憑證，方法是在將簽署該憑證的 CA 憑證放在其信任存放區中。 此程序稱為信任分送或信任組合。 請務必了解用戶端驗證與伺服器驗證之間的差異：

  • 用戶端驗證：MQTT 代理程式 (伺服器) 會根據 trustedClientCaCert 欄位中指定的受信任 CA 憑證來檢查用戶端憑證，以進行 X.509 用戶端驗證。
  • 伺服器驗證：用戶端 (例如 Mosquitto 或 MQTTX) 會根據信任存放區中受信任的 CA 憑證檢查 MQTT 代理程式的伺服器憑證。 針對 Mosquitto 用戶端，請使用 --cafile 參數來指定 CA 憑證檔案。 針對 MQTTX，請將 CA 憑證新增至設定中的信任存放區。

啟用 X.509 驗證之後，請確保用戶端在信任存放區中有伺服器端 CA 憑證，以信任代理程式的伺服器憑證。 請勿將信任伺服器端 CA 憑證與用於用戶端驗證的用戶端 CA 憑證 (在 trustedClientCaCert 欄位中指定) 混淆。

如需完整範例，請參閱教學課程：TLS、X.509 用戶端驗證和屬性型存取控制 (ABAC) 授權。

使用 X.509 用戶端憑證將 Mosquitto 用戶端連線到 MQTT 代理程式

像 Mosquitto 這樣的用戶端需要兩個檔案，才能使用 TLS 和 X.509 用戶端驗證連線到 MQTT 代理程式：

  • --cert 參數指定用戶端憑證 PEM 檔案。 此檔案也應該包含任何中繼憑證，以協助 MQTT 代理程式建置完整的憑證鏈結。
  • --key 參數指定用戶端私密金鑰 PEM 檔案。

如果 MQTT 代理程式使用自我簽署的 CA 憑證發出其 TLS 伺服器憑證，則需要 --cafile 參數。 此檔案包含 CA 憑證 (也稱為信任套件組合)，Mosquitto 用戶端會在透過 TLS 連線時用來驗證代理程式的伺服器憑證。 如果 MQTT 代理程式伺服器憑證的簽發者是系統根存放區的一部分 (例如已知的公用 CA)，則可以省略 --cafile 參數。

例如：

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

了解 MQTT 代理程式 X.509 用戶端驗證流程

顯示 X.509 用戶端驗證流程的圖表。

遵循下列步驟進行用戶端驗證：

  1. 當 X.509 用戶端驗證開啟時，連線用戶端必須呈現其用戶端憑證和任何中繼憑證，讓 MQTT 代理程式建置根在其中一個設定的受信任憑證的憑證鏈結。
  2. 負載平衡器會將通訊導向至其中一個前端訊息代理程式。
  3. 一旦前端代理程式收到用戶端憑證，它會嘗試建置根在其中一個已設定憑證的憑證鏈結。 如果前端代理程式已成功建置鏈結且呈現的鏈結經過驗證，則會完成 TLS 交握。 連線用戶端可以透過 TLS 通道，將 MQTT 封包傳送至前端。
  4. TLS 通道已開啟，但用戶端驗證或授權尚未完成。
  5. 用戶端接著會將 CONNECT 封包傳送至 MQTT 代理程式。
  6. CONNECT 封包會再次路由傳送至前端。
  7. 前端會收集到目前為止呈現的所有用戶端認證，例如來自 CONNECT 封包的驗證資料，以及 TLS 交握期間呈現的用戶端憑證鏈結。
  8. 前端會將這些憑證傳送至驗證服務。 驗證服務會再次檢查憑證鏈結，並收集鏈結中所有憑證的主體名稱。
  9. 驗證服務會使用其設定的授權規則，來判斷連線用戶端具有哪些屬性。 這些屬性會決定用戶端可執行哪些作業，包括 CONNECT 封包本身。
  10. 驗證服務會將決策傳回給前端代理程式。
  11. 前端訊息代理程式知道用戶端屬性，以及它是否允許連線。 如果是，則 MQTT 連線已完成，而且用戶端可以繼續傳送和接收由其授權規則決定的 MQTT 封包。

Kubernetes 服務帳戶權杖

Kubernetes SAT 是與 Kubernetes 服務帳戶相關聯的 JSON Web 權杖。 用戶端向 MQTT 代理程式出示 SAT，以自行驗證。

MQTT 代理程式會使用繫結服務帳戶權杖，其於GKE 使用者應該要知道關於 Kubernetes 新服務帳戶權杖的事項文章中詳述。 以下是該文章的主要功能：

繫結權杖是在 Kubernetes 1.13 中啟動，並成為 1.21 中的預設格式。 繫結權杖可解決舊版權杖的所有有限功能，以及更多功能：

  • 權杖難以竊取和誤用。 它們是時間繫結、對象繫結和物件繫結。
  • 它們採用標準化格式。 OpenID Connect (OIDC)，具有完整的 OIDC 探索，可讓服務提供者更容易接受。
  • 它們使用新的 Kubelet 投影磁碟區類型，更安全地散發到 Pod。

代理程式會使用 Kubernetes 權杖檢閱 API 來驗證權杖。 啟用 Kubernetes TokenRequestProjection 功能來指定 audiences (自 1.21 起的預設值)。 如果未啟用此功能，您就無法使用 SAT。

建立服務帳戶

若要建立 SAT，請先建立服務帳戶。 下列命令會建立名為 mqtt-client 的服務帳戶：

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

選用：新增授權的屬性

透過 SAT 的用戶端驗證可以選擇性地使用屬性標註其服務帳戶，以搭配授權原則使用。 為了區別這些註釋與其他註釋，其開頭為 aio-broker-auth/ 前置詞。

您可以使用 kubectl annotate 來標註服務帳戶：

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

或者，您可以將註釋新增至服務帳戶資訊清單檔：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

若要深入了解，請參閱授權使用 Kubernetes 服務帳戶權杖的用戶端。

啟用 SAT 驗證

修改 BrokerAuthentication 資源中的 authenticationMethods 設定，將 ServiceAccountToken 指定為有效的驗證方法。 audiences 參數會指定權杖的有效對象清單。 選擇可識別 MQTT 代理程式服務的唯一值。 您必須指定至少一個對象，且所有 SAT 都必須符合其中一個指定的對象。

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。
  2. 在 [元件] 底下，選取 [MQTT 代理程式]。
  3. 選取 [驗證] 索引標籤。
  4. 選擇現有的驗證原則或建立新的驗證原則。
  5. 選取 [新增方法] 以新增方法。
  6. 從下拉式清單中選擇方法類型 Kubernetes SAT。 然後選取 [新增詳細資料] 以設定 方法。

顯示使用 Azure 入口網站來設定 MQTT 代理程式 SAT 驗證方法的螢幕擷取畫面。

測試 SAT 驗證

SAT 驗證會使用 MQTT v5 增強式驗證欄位。 用戶端必須將增強式驗證方法設定為 K8S-SAT，並將增強式驗證資料設定為權杖。

例如，使用 Mosquitto (為求簡潔，會省略某些欄位)：

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

在這裡，<TOKEN> 是服務帳戶權杖。 若要取得測試權杖，請執行：

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

在這裡，<SERVICE_ACCOUNT> 是您建立的服務帳戶名稱，而 <AUDIENCE> 是在 BrokerAuthentication 資源中設定的其中一個對象。

如需如何設定 Kubernetes Pod 以使用 SAT 驗證的範例，請參閱連線到叢集內的預設接聽程式。

在 Pod 設定中，serviceAccountName 欄位必須符合與所使用的權杖相關聯的服務帳戶。 serviceAccountToken.audience 欄位必須是 BrokerAuthentication 資源中設定的其中一個 audiences。

重新整理服務帳戶權杖

服務帳戶權杖在有限的時間內有效，並使用 expirationSeconds 進行設定。 不過，Kubernetes 會在權杖到期之前自動重新整理。 權杖會在背景重新整理，用戶端不需要執行任何其他動作，即可再次擷取權杖。

例如，如果用戶端是使用掛接為磁碟區的權杖的 Pod，例如在測試 SAT 驗證範例中，則會在相同的路徑 /var/run/secrets/tokens/broker-sat 取得最新的權杖。 當用戶端進行新的連線時，用戶端可以擷取最新的權杖，並使用它進行驗證。 用戶端也應該有一個機制，藉由擷取最新的權杖並重試連線，來處理 MQTT 的未授權錯誤。

自訂驗證

使用自訂驗證，將用戶端驗證延伸至提供的驗證方法之外。 服務可以是任何項目，但只要服務遵守 API，即視為可插入。

當用戶端連線到已啟用自訂驗證的 MQTT 代理程式時，代理程式會使用用戶端的認證，將 HTTPS 要求傳送至自訂驗證伺服器。 然後，伺服器會以核准或拒絕回應，包括用戶端的授權屬性。

建立自訂驗證服務

自訂驗證伺服器會與 MQTT 代理程式分開實作和部署。

GitHub 提供範例自訂驗證伺服器和指示。 使用此範例做為範本，以及實作您自己的自訂驗證邏輯的起點。

API

MQTT 代理程式與自訂驗證伺服器之間的 API 遵循自訂驗證的 API 規格。 GitHub 提供 OpenAPI 規格。

需要具有 TLS 加密的 HTTPS

MQTT 代理程式會將包含敏感性用戶端認證的要求傳送至自訂驗證伺服器。 若要保護這些認證，MQTT 代理程式與自訂驗證伺服器之間的通訊必須使用 TLS 加密。

自訂驗證伺服器必須出示伺服器憑證，而 MQTT 代理程式必須具有受信任的根 CA 憑證，才能驗證伺服器憑證。 或者，自訂驗證伺服器可能需要 MQTT 代理程式來呈現用戶端憑證以自行驗證。

啟用接聽程式的自訂驗證

修改 BrokerAuthentication 資源中的驗證方法設定，將 Custom 指定為有效的驗證方法。 然後，指定與自定驗證伺服器通訊所需的參數。

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。

  2. 在 [元件] 底下，選取 [MQTT 代理程式]。

  3. 選取 [驗證] 索引標籤。

  4. 選擇現有的驗證原則或建立新的驗證原則。

  5. 選取 [新增方法] 以新增方法。

  6. 從下拉式清單中選擇 [自訂] 方法類型。 然後選取 [新增詳細資料] 以設定 方法。

    顯示使用 Azure 入口網站來設定 MQTT 代理程式自訂驗證方法的螢幕擷取畫面。

使用自訂驗證進行使用者名稱和密碼驗證

您可以使用自訂驗證來實作使用者名稱和密碼驗證。 範例自定義驗證伺服器範例可用於測試。 請參閱 GitHub 上的 Azure IoT Operations MQTT 使用者名稱和密碼驗證範例 。

停用驗證

若要進行測試，您可以停用代理程式接聽程式連接埠的驗證。 不建議停用生產環境的驗證。

  1. 在 Azure 入口網站中，移至您的 IoT 操作執行個體。
  2. 在 [元件] 底下，選取 [MQTT 代理程式]。
  3. 從清單中選取您要編輯的代理程式接聽程式。
  4. 在您要停用驗證的連接埠上，選取 [驗證] 下拉式清單中的 [無]。

用戶端在認證過期後中斷連線

MQTT 代理程式會在用戶端的認證過期時將用戶端中斷連線。 在認證過期後中斷連線的做法適用於所有連線到 MQTT 代理程式前端的用戶端，例如：

  • 使用 SAT 進行驗證的用戶端會在其 SAT 過期時中斷連線。
  • 使用 X.509 進行驗證的用戶端會在用戶端憑證過期時中斷連線。
  • 使用自訂驗證來進行驗證的用戶端會根據自訂驗證伺服器所傳回的過期時間來中斷連線。

在中斷連線時，用戶端的網路連線會關閉。 用戶端不會收到 MQTT DISCONNECT 封包，但代理程式會記錄其將用戶端中斷連線的訊息。

使用 SAT 和自訂驗證來進行驗證的 MQTT v5 用戶端可以在初始認證過期前，使用新的認證重新驗證。 X.509 用戶端則無法重新驗證，而且因為是在 TLS 層進行驗證的，因此必須重新建立連線。

用戶端可以藉由傳送 MQTT v5 AUTH 封包來重新驗證，原因為 ReAuth。

SAT 用戶端會傳送具有欄位 method: K8S-SAT 和 data: <token> 的 AUTH 用戶端。 自訂驗證用戶端會按照自訂驗證伺服器的要求來設定方法和資料欄位。

成功重新驗證會使用其新認證到期時間更新用戶端的認證到期日。 代理程式會以 Success AUTH 封包回應。 由於暫時性問題，例如自訂驗證伺服器無法使用，導致代理程式以 ContinueAuthentication AUTH 封包回應，使得驗證失敗。 用戶端可以稍後再試一次。 其他驗證失敗則會導致代理程式傳送 DISCONNECT 封包，並關閉用戶端的網路連線。

相關內容

  • Last updated on