Konfigurera MQTT-asynkron autentisering
Viktigt!
Den här sidan innehåller instruktioner för att hantera Azure IoT Operations-komponenter med hjälp av Kubernetes-distributionsmanifest, som finns i förhandsversion. Den här funktionen har flera begränsningar och bör inte användas för produktionsarbetsbelastningar.
Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.
MQTT Broker stöder flera autentiseringsmetoder för klienter, och du kan konfigurera varje lyssnarport så att den har egna autentiseringsinställningar med en BrokerAuthentication-resurs . En lista över tillgängliga inställningar finns i referensen för API:et för autentisering med asynkron autentisering .
Länka BrokerListener och BrokerAuthentication
Följande regler gäller för relationen mellan BrokerListener- och BrokerAuthentication-resurser :
- Varje BrokerListener kan ha flera portar. Varje port kan länkas till en BrokerAuthentication-resurs .
- Varje BrokerAuthentication kan ha stöd för flera autentiseringsmetoder samtidigt.
- Portar som inte länkar en BrokerAuthentication-resurs har autentisering inaktiverad.
Om du vill länka en BrokerListener-port till en BrokerAuthentication-resurs anger du authenticationRef fältet i ports inställningen för BrokerListener-resursen. Mer information finns i BrokerListener-resurs.
Standardresurs för BrokerAuthentication
Azure IoT Operations distribuerar en standardresurs för BrokerAuthentication med namnet länkad default med standardlyssnaren azure-iot-operations i namnområdet. Den använder bara Kubernetes-tjänstkontotoken (SAT) för autentisering.
Viktigt!
Autentiseringsmetoden för tjänstkontotoken (SAT) i standardresursen BrokerAuthentication krävs för att komponenter i Azure IoT Operations ska fungera korrekt. Undvik att uppdatera eller ta bort standardresursen BrokerAuthentication .
I Azure Portal navigerar du till din IoT Operations-instans.
Under Komponenter väljer du MQTT Broker.
Markera fliken autentisering.
I listan över autentiseringsprinciper väljer du standardprincipnamnet .
Om du vill lägga till nya autentiseringsmetoder väljer du Lägg till metod.
Autentiseringsflöde
Ordningen på de angivna autentiseringsmetoderna avgör hur MQTT-autentiserar klienter. MQTT-broker försöker autentisera klientens autentiseringsuppgifter med den första angivna metoden och itererar genom de angivna metoderna tills den hittar en matchning eller når slutet.
För varje metod kontrollerar MQTT Broker först om klientens autentiseringsuppgifter är relevanta för den metoden. Sat-autentisering kräver till exempel ett användarnamn som börjar med K8S-SAT, och X.509-autentisering kräver ett klientcertifikat. Om klientens autentiseringsuppgifter är relevanta verifierar MQTT-koordinatorn om de är giltiga. Mer information finns i avsnittet Konfigurera autentiseringsmetod .
För anpassad autentisering behandlar MQTT Broker att det inte går att kommunicera med den anpassade autentiseringsservern som autentiseringsuppgifter som inte är relevanta. Med det här beteendet kan MQTT-koordinatorn återgå till andra metoder om den anpassade autentiseringsservern inte kan nås.
Autentiseringsflödet slutar när:
- Ett av dessa villkor är sant:
- Klientens autentiseringsuppgifter är relevanta och giltiga för någon av metoderna.
- Klientens autentiseringsuppgifter är inte relevanta för någon av metoderna.
- Klientens autentiseringsuppgifter är relevanta men ogiltiga för någon av metoderna.
- MQTT-asynkron meddelandekö beviljar eller nekar åtkomst till klienten baserat på resultatet av autentiseringsflödet.
Till exempel:
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
I det tidigare exemplet anges anpassade och SAT. När en klient ansluter försöker MQTT-koordinatorn autentisera klienten med de angivna metoderna i den anpassade ordningen och sedan SAT.
- MQTT-koordinator kontrollerar om klientens autentiseringsuppgifter är giltiga för anpassad autentisering. Eftersom anpassad autentisering förlitar sig på en extern server för att fastställa autentiseringsuppgifternas giltighet, tar mäklaren hänsyn till alla autentiseringsuppgifter som är relevanta för anpassad autentisering och vidarebefordrar dem till den anpassade autentiseringsservern.
- Om den anpassade autentiseringsservern svarar med
PassellerFailresulterar upphör autentiseringsflödet. Men om den anpassade autentiseringsservern inte är tillgänglig återgår MQTT-koordinatorn till de återstående angivna metoderna, där SAT står på tur. - MQTT Broker försöker autentisera autentiseringsuppgifterna som SAT-autentiseringsuppgifter.
Om den anpassade autentiseringsservern inte är tillgänglig och alla efterföljande metoder fastställer att de angivna autentiseringsuppgifterna inte är relevanta nekar mäklaren klientanslutningen.
Konfigurera autentiseringsmetod
Du kan lägga till autentiseringsmetoder som X.509, SAT eller anpassade till autentiseringsprinciper.
Så här lägger du till en autentiseringsmetod i en princip:
I Azure Portal navigerar du till din IoT Operations-instans.
Under Komponenter väljer du MQTT Broker.
Markera fliken autentisering.
Välj en befintlig autentiseringsprincip eller skapa en ny.
Lägg till en ny metod genom att välja Lägg till metod.
Välj metodtypen i listrutan och välj sedan Lägg till information för att konfigurera metoden.
Mer information om vart och ett av autentiseringsalternativen finns i nästa avsnitt för varje metod.
Mer information om hur du aktiverar säkra inställningar genom att konfigurera ett Azure Key Vault och aktivera arbetsbelastningsidentiteter finns i Aktivera säkra inställningar i Azure IoT Operations-distribution.
X.509
Dricks
Ett exempel från slutpunkt till slutpunkt på hur du konfigurerar X.509-autentisering finns i Självstudie: TLS, X.509-klientautentisering och auktorisering för attributbaserad åtkomstkontroll (ABAC).
Med X.509-autentisering använder MQTT-koordinatorn ett betrott CA-certifikat för att validera klientcertifikat. Den här betrodda certifikatutfärdare kan vara en rot- eller mellanliggande certifikatutfärdare. Koordinatorn kontrollerar klientcertifikatkedjan mot det betrodda CA-certifikatet. Om kedjan är giltig autentiseras klienten.
Om du vill använda X.509-autentisering med ett betrott CA-certifikat måste följande krav uppfyllas:
- TLS: Eftersom X.509 förlitar sig på TLS-klientcertifikat måste TLS vara aktiverat för portar med X.509-autentisering.
- Nyckelalgoritmer: Både EC- och RSA-nycklar stöds, men alla certifikat i kedjan måste använda samma nyckelalgoritm.
- Format: CA-certifikatet måste vara i PEM-format.
Dricks
PEM-format är ett vanligt format för certifikat och nycklar. PEM-filer är base64-kodade ASCII-filer med rubriker som -----BEGIN CERTIFICATE----- och -----BEGIN EC PRIVATE KEY-----.
Om du har ett certifikat i ett annat format kan du konvertera det till PEM med hjälp av OpenSSL. Mer information finns i Så här konverterar du ett certifikat till rätt format.
Hämta ett betrott CA-certifikat
I en produktionskonfiguration tillhandahålls CA-certifikatet av en organisations offentliga nyckelinfrastruktur (PKI) eller en offentlig certifikatutfärdare.
För testning skapar du ett självsignerat CA-certifikat med OpenSSL. Kör till exempel följande kommando för att generera ett självsignerat CA-certifikat med en RSA-nyckel, ett unikt namn CN=Contoso Root CA Certoch en giltighet på 365 dagar:
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
Samma kommando med Step CLI, som är ett praktiskt verktyg för att hantera certifikat, är:
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
Dessa kommandon skapar ett CA-certifikat ca.pem och en privat nyckel ca-key.pem i PEM-format. CA-certifikatet ca.pem kan importeras till MQTT-koordinatorn för X.509-autentisering.
Importera ett betrott CA-certifikat
Kom igång med X.509-autentisering genom att importera det betrodda CA-certifikatet till en ConfigMap i azure-iot-operations namnområdet. Om du vill importera ett betrott CA-certifikat ca.pem till en ConfigMap med namnet client-cakör du:
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
I det här exemplet importeras CA-certifikatet under nyckeln ca.pem. MQTT Broker litar på alla CA-certifikat i ConfigMap, så att namnet på nyckeln kan vara vad som helst.
Om du vill kontrollera att rotcertifikatutfärdarcertifikatet har importerats korrekt kör du kubectl describe configmap. Resultatet visar samma base64-kodning av PEM-certifikatfilen.
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
====
Konfigurera X.509-autentiseringsmetod
När det betrodda CA-certifikatet har importerats aktiverar du X.509-klientautentisering genom att lägga till det som en autentiseringsmetod i en BrokerAuthentication-resurs . Kontrollera att den här resursen är länkad till en TLS-aktiverad lyssnarport.
I Azure Portal navigerar du till din IoT Operations-instans.
Under Komponenter väljer du MQTT Broker.
Markera fliken autentisering.
Välj en befintlig autentiseringsprincip eller skapa en ny.
Lägg till en ny metod genom att välja Lägg till metod.
Välj metodtypen X.509 i listrutan och välj sedan Lägg till information för att konfigurera metoden.
I fönstret X.509-autentiseringsinformation anger du namnet på det betrodda CA-certifikatet ConfigMap med JSON-format.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Ersätt
<TRUSTED_CA_CONFIGMAP>med namnet på ConfigMap som innehåller det betrodda CA-certifikatet. Exempel:"trustedClientCaCert": "client-ca"
Du kan också lägga till auktoriseringsattribut för klienter som använder X.509-certifikat. Mer information finns i Certifikatattribut för auktorisering.
Spara ändringarna genom att välja Använd .
Valfritt: Certifikatattribut för auktorisering
X.509-attribut kan anges i BrokerAuthentication-resursen för att auktorisera klienter baserat på deras certifikategenskaper. Attributen definieras i fältet authorizationAttributes .
Till exempel:
När du konfigurerar X.509-autentiseringsmetoden i Azure Portal lägger du till auktoriseringsattributen i fönstret X.509-autentiseringsinformation i JSON-format.
{
"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"
}
}
}
}
I det här exemplet tar varje klient som har ett certifikat utfärdat av rotcertifikatutfärdare med unikt namn CN = Contoso Root CA Cert, OU = Engineering, C = US eller den mellanliggande certifikatutfärdare med unikt namn CN = Contoso Intermediate CA emot de attribut som anges. Dessutom tar smart-klientcertifikatet emot attribut som är specifika för det.
Matchningen för attribut börjar alltid från lövklientcertifikatet och går sedan längs kedjan. Attributtilldelningen stoppas efter den första matchningen. I föregående exempel, även om smart-fan det har det mellanliggande certifikatet CN = Contoso Intermediate CA, hämtar det inte de associerade attributen.
Auktoriseringsregler kan tillämpas på klienter som använder X.509-certifikat med dessa attribut. Mer information finns i Auktorisera klienter som använder X.509-autentisering.
Aktivera X.509-autentisering för en lyssnarport
När du har importerat det betrodda CA-certifikatet och konfigurerat BrokerAuthentication-resursen länkar du det till en TLS-aktiverad lyssnarport. Det här steget är viktigt eftersom X.509-autentisering förlitar sig på TLS för verifiering av klientcertifikat.
Information om hur du hämtar en TLS-aktiverad lyssnarport finns i Aktivera manuell TLS-certifikathantering för en port och Aktivera automatisk TLS-certifikathantering för en port.
Kommentar
Om du aktiverar TLS på en koordinatorlyssnareport innebär det att asynkron meddelandekö använder ett servercertifikat för TLS-kryptering. När klienter ansluter till den här porten måste de lita på servercertifikatet genom att ha certifikatutfärdarcertifikatet som signerade det i deras förtroendearkiv. Den här processen kallas förtroendedistribution eller förtroendepaketering. Det är viktigt att förstå skillnaden mellan serververifiering och klientvalidering:
- Klientverifiering: MQTT-koordinatorn (servern) kontrollerar klientcertifikatet mot det betrodda CA-certifikatet
trustedClientCaCertsom anges i fältet för X.509-klientautentisering. - Serververifiering: Klienter (t.ex. mosquitto eller MQTTX) kontrollerar MQTT-koordinatorns servercertifikat mot det betrodda CA-certifikatet i deras förtroendearkiv. För mosquitto-klienter använder du parametern
--cafileför att ange CA-certifikatfilen. För MQTTX lägger du till CA-certifikatet i förtroendearkivet i inställningarna.
När du har aktiverat X.509-autentisering ska du se till att klienterna litar på mäklarens servercertifikat genom att ha ca-certifikatet på serversidan i sitt förtroendearkiv. Förväxla inte förtroende för ca-certifikatet på serversidan med ca-certifikatet på klientsidan som används för klientautentisering som anges i fältettrustedClientCaCert.
Ett fullständigt exempel finns i Självstudie: TLS, X.509-klientautentisering och auktorisering för attributbaserad åtkomstkontroll (ABAC).
Ansluta mosquitto-klienten till MQTT-koordinatorn med X.509-klientcertifikat
En klient som mosquitto behöver två filer för att kunna ansluta till MQTT-koordinator med TLS- och X.509-klientautentisering.
- Parametern
--certanger PEM-filen för klientcertifikatet. Den här filen bör även innehålla mellanliggande certifikat som hjälper MQTT-koordinatorn att skapa den fullständiga certifikatkedjan. - Parametern
--keyanger PEM-filen för klientens privata nyckel.
I de fall där MQTT Broker använder ett självsignerat CA-certifikat för att utfärda sitt TLS-servercertifikat krävs parametern --cafile . Den här filen innehåller certifikatutfärdarcertifikatet (även kallat förtroendepaket) som mosquitto-klienten använder för att verifiera koordinatorns servercertifikat vid anslutning via TLS. Om utfärdaren av MQTT Brokers servercertifikat är en del av systemets rotarkiv (till exempel välkända offentliga certifikatutfärdare) kan parametern --cafile utelämnas.
Till exempel:
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
Förstå X.509-klientautentiseringsflödet för MQTT-koordinator
Följande är stegen för klientautentisering:
- När X.509-klientautentisering är aktiverat måste anslutande klienter presentera ett klientcertifikat och eventuella mellanliggande certifikat så att MQTT-koordinatorn kan skapa en certifikatkedja som är rotad till ett av dess konfigurerade betrodda certifikat.
- Lastbalanseraren dirigerar kommunikationen till en av klientdelsmäklarna.
- När klientdelskoordinatorn har tagit emot klientcertifikatet försöker den skapa en certifikatkedja som är rotad till ett av de konfigurerade certifikaten. Om klientdelskoordinatorn har skapat en kedja och den presenterade kedjan har verifierats slutför den TLS-handskakningen. Den anslutande klienten kan skicka MQTT-paket till klientdelen via TLS-kanalen.
- TLS-kanalen är öppen, men klientautentiseringen eller auktoriseringen är inte klar än.
- Klienten skickar sedan ett CONNECT-paket till MQTT-asynkron meddelandekö.
- CONNECT-paketet dirigeras till en klientdel igen.
- Klientdelen samlar in alla autentiseringsuppgifter som klienten har presenterat hittills, till exempel autentiseringsdata från CONNECT-paketet och klientcertifikatkedjan som presenterades under TLS-handskakningen.
- Klientdelen skickar dessa autentiseringsuppgifter till autentiseringstjänsten. Autentiseringstjänsten kontrollerar certifikatkedjan igen och samlar in ämnesnamnen för alla certifikat i kedjan.
- Autentiseringstjänsten använder sina konfigurerade auktoriseringsregler för att avgöra vilka attribut de anslutande klienterna har. Dessa attribut avgör vilka åtgärder klienten kan köra, inklusive själva CONNECT-paketet.
- Autentiseringstjänsten returnerar beslutet till klientdelskoordinatorn.
- Klientdelskoordinatorn känner till klientattributen och om den tillåts ansluta. I så fall slutförs MQTT-anslutningen och klienten kan fortsätta att skicka och ta emot MQTT-paket enligt auktoriseringsreglerna.
Kubernetes-tjänstkontotoken
Kubernetes-tjänstkontotoken (SAT) är JSON-webbtoken som är associerade med Kubernetes-tjänstkonton. Klienter presenterar SAT för MQTT-koordinatorn för att autentisera sig själva.
MQTT Broker använder token för bundna tjänstkonton som beskrivs i vad GKE-användare behöver veta om Kubernetes nya tjänstkontotoken . Här är de viktigaste funktionerna från inlägget:
Den startades i Kubernetes 1.13 och blev standardformatet i 1.21, bundna token hanterar alla begränsade funktioner i äldre token med mera:
- Själva token är svårare att stjäla och missbruka; de är tidsbundna, målgruppsbundna och objektbundna.
- De använder ett standardiserat format: OpenID Connect (OIDC), med fullständig OIDC-identifiering, vilket gör det enklare för tjänsteleverantörer att acceptera dem.
- De distribueras till poddar på ett säkrare sätt med hjälp av en ny Kubelet-beräknad volymtyp.
Asynkron meddelandekö verifierar token med hjälp av API:et för Granskning av Kubernetes-token. Aktivera Kubernetes-funktionen TokenRequestProjection för att ange audiences (standard sedan 1.21). Om den här funktionen inte är aktiverad kan inte SAT användas.
Skapa ett tjänstkonto
Skapa SAT:er genom att först skapa ett tjänstkonto. Följande kommando skapar ett tjänstkonto med namnet mqtt-client.
kubectl create serviceaccount mqtt-client -n azure-iot-operations
Valfritt: Lägg till attribut för auktorisering
Klienter som autentiserar via SAT kan också få sina tjänstkonton kommenterade med attribut som ska användas med auktoriseringsprinciper. För att skilja dessa anteckningar från andra börjar de med aio-broker-auth/ prefix.
Du kan kommentera ett tjänstkonto med hjälp av kubectl annotate:
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
Eller så kan du lägga till anteckningarna i tjänstkontots manifestfil:
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>
Mer information finns i Auktorisera klienter som använder Kubernetes-tjänstkontotoken.
Aktivera SAT-autentisering (Service Account Token)
Ändra inställningen authenticationMethods i en BrokerAuthentication-resurs för att ange ServiceAccountToken som en giltig autentiseringsmetod. audiences Anger listan över giltiga målgrupper för token. Välj unika värden som identifierar MQTT-koordinatortjänsten. Du måste ange minst en målgrupp och alla SAT måste matcha en av de angivna målgrupperna.
- I Azure Portal navigerar du till din IoT Operations-instans.
- Under Komponenter väljer du MQTT Broker.
- Markera fliken autentisering.
- Välj en befintlig autentiseringsprincip eller skapa en ny.
- Lägg till en ny metod genom att välja Lägg till metod.
- Välj metodtypen Kubernetes SAT i listrutan och välj sedan Lägg till information för att konfigurera metoden.
Testa SAT-autentisering
SAT-autentisering använder de förbättrade MQTT v5-autentiseringsfälten. En klient måste ange den förbättrade autentiseringsmetoden till K8S-SAT och utökade autentiseringsdata till token.
Till exempel med mosquitto (vissa fält utelämnas för korthet):
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
<TOKEN> Här är tjänstkontotoken. Kör för att hämta en testtoken:
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
<SERVICE_ACCOUNT> Här är namnet på tjänstkontot som du skapade och <AUDIENCE> är en av målgrupperna som konfigurerats i BrokerAuthentication-resursen.
Ett exempel på hur du konfigurerar en Kubernetes-podd för användning av SAT-autentisering finns i Ansluta till standardlyssnaren i klustret.
I poddkonfigurationen serviceAccountName måste fältet i matcha det tjänstkonto som är associerat med den token som används, och serviceAccountToken.audience fältet måste vara en av de audiences konfigurerade i BrokerAuthentication-resursen .
Uppdatera tjänstkontotoken
Tjänstkontotoken är giltiga under en begränsad tid och konfigureras med expirationSeconds. Kubernetes uppdaterar dock token automatiskt innan den upphör att gälla. Token uppdateras i bakgrunden och klienten behöver inte göra något annat än att hämta den igen.
Om klienten till exempel är en podd som använder token monterad som en volym, som i exemplet med SAT-testautentisering , är den senaste token tillgänglig på samma sökväg /var/run/secrets/tokens/broker-sat. När du skapar en ny anslutning kan klienten hämta den senaste token och använda den för att autentisera. Klienten bör också ha en mekanism för att hantera MQTT-obehöriga fel genom att hämta den senaste token och försöka ansluta igen.
Anpassad autentisering
Utöka klientautentisering utöver de angivna autentiseringsmetoderna med anpassad autentisering. Den kan anslutas eftersom tjänsten kan vara vad som helst så länge den följer API:et.
När en klient ansluter till MQTT-koordinatorn med anpassad autentisering aktiverad skickar asynkron meddelandekö en HTTPS-begäran till en anpassad autentiseringsserver med klientens autentiseringsuppgifter. Servern svarar sedan med antingen godkännande eller nekande, inklusive klientens auktoriseringsattribut.
Skapa en anpassad autentiseringstjänst
Den anpassade autentiseringsservern implementeras och distribueras separat från MQTT-koordinatorn.
En anpassad exempelautentiseringsserver och instruktioner finns på GitHub. Använd det här exemplet som en mall kan och startpunkt för att implementera din egen anpassade autentiseringslogik.
API
API:et mellan MQTT-koordinatorn och den anpassade autentiseringsservern följer API-specifikationen för anpassad autentisering. OpenAPI-specifikationen är tillgänglig på GitHub.
HTTPS med TLS-kryptering krävs
MQTT Broker skickar begäranden som innehåller känsliga klientautentiseringsuppgifter till den anpassade autentiseringsservern. För att skydda dessa autentiseringsuppgifter måste kommunikationen mellan MQTT-koordinatorn och den anpassade autentiseringsservern krypteras med TLS.
Den anpassade autentiseringsservern måste visa ett servercertifikat och MQTT-koordinatorn måste ha ett betrott rotcertifikatutfärdarcertifikat för att verifiera servercertifikatet. Om du vill kan den anpassade autentiseringsservern kräva att MQTT-koordinatorn presenterar ett klientcertifikat för att autentisera sig själv.
Aktivera anpassad autentisering för en lyssnare
Ändra inställningen authenticationMethods i en BrokerAuthentication-resurs för att ange Custom som en giltig autentiseringsmetod. Ange sedan de parametrar som krävs för att kommunicera med en anpassad autentiseringsserver.
I Azure Portal navigerar du till din IoT Operations-instans.
Under Komponenter väljer du MQTT Broker.
Markera fliken autentisering.
Välj en befintlig autentiseringsprincip eller skapa en ny.
Lägg till en ny metod genom att välja Lägg till metod.
Välj metodtypen Anpassad i listrutan och välj sedan Lägg till information för att konfigurera metoden.
Inaktivera autentisering
För testning kan du inaktivera autentisering för en koordinatorlyssnareport. Att inaktivera autentisering rekommenderas inte för produktionsmiljöer.
- I Azure Portal navigerar du till din IoT Operations-instans.
- Under Komponenter väljer du MQTT Broker.
- Välj den koordinatorlyssnare som du vill redigera i listan.
- På den port som du vill inaktivera autentisering väljer du Ingen i listrutan för autentisering.
Klienter kopplas från när autentiseringsuppgifterna har upphört att gälla
MQTT-koordinator kopplar från klienter när deras autentiseringsuppgifter upphör att gälla. Frånkoppling efter förfallodatum för autentiseringsuppgifter gäller för alla klienter som ansluter till MQTT-koordinatorklientdelarna, inklusive:
- Klienter som autentiseras med SAT kopplas från när deras SAT upphör att gälla
- Klienter som autentiseras med X.509 kopplas från när deras klientcertifikat upphör att gälla
- Klienter autentiserade med anpassad frånkoppling av autentisering baserat på förfallotiden som returnerades från den anpassade autentiseringsservern.
Vid frånkoppling stängs klientens nätverksanslutning. Klienten tar inte emot ett MQTT DISCONNECT-paket, men mäklaren loggar ett meddelande om att klienten kopplades från.
MQTT v5-klienter som autentiseras med SAT och anpassad autentisering kan autentiseras igen med en ny autentiseringsuppgift innan deras första autentiseringsuppgifter upphör att gälla. X.509-klienter kan inte autentiseras igen och måste återupprätta anslutningen eftersom autentiseringen görs på TLS-lagret.
Klienter kan autentisera igen genom att skicka ett MQTT v5 AUTH-paket med anledning ReAuth.
SAT-klienter skickar en AUTH-klient med fälten method: K8S-SAT, data: <token>.
Anpassade autentiseringsklienter anger metod- och datafältet som krävs av den anpassade autentiseringsservern.
Lyckad omautentisering uppdaterar klientens förfallotid för autentiseringsuppgifter med förfallotiden för den nya autentiseringsuppgiften, och koordinatorn svarar med ett Lyckat AUTH-paket. Misslyckad autentisering på grund av tillfälliga problem, till exempel att den anpassade autentiseringsservern inte är tillgänglig, gör att asynkroniseraren svarar med ett ContinueAuthentication AUTH-paket. Klienten kan försöka igen senare. Andra autentiseringsfel gör att asynkron meddelandekö skickar ett DISCONNECT-paket och stänger klientens nätverksanslutning.