Konfigurace ověřování zprostředkovatele MQTT
Důležité
Tato stránka obsahuje pokyny ke správě komponent operací Azure IoT pomocí manifestů nasazení Kubernetes, které jsou ve verzi Preview. Tato funkce je poskytována s několika omezeními a neměla by se používat pro produkční úlohy.
Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.
Zprostředkovatel MQTT podporuje více metod ověřování pro klienty a každý port naslouchacího procesu můžete nakonfigurovat tak, aby měl vlastní nastavení ověřování pomocí prostředku BrokerAuthentication . Seznam dostupných nastavení najdete v referenčních informacích k rozhraní API pro ověřování zprostředkovatele.
Propojení BrokerListener a BrokerAuthentication
Následující pravidla platí pro vztah mezi prostředky BrokerListener a BrokerAuthentication :
- Každý brokerListener může mít více portů. Každý port může být propojený s prostředkem BrokerAuthentication .
- Každá metoda BrokerAuthentication může podporovat více metod ověřování najednou.
- Porty, které nepřipojuje prostředek BrokerAuthentication , mají zakázané ověřování.
Pokud chcete propojit port BrokerListener s prostředkem BrokerAuthentication , zadejte authenticationRef pole v ports nastavení prostředku BrokerListener. Další informace najdete v tématu Prostředek BrokerListener.
Výchozí prostředek BrokerAuthentication
Operace Azure IoT nasadí výchozí prostředek BrokerAuthentication s názvem default propojeným s výchozím naslouchacím procesem azure-iot-operations v oboru názvů. K ověřování používá pouze tokeny účtů služby Kubernetes Service.
Důležité
Metoda ověřování tokenu účtu služby (SAT) ve výchozím prostředku BrokerAuthentication je nutná pro správné fungování komponent v operacích Azure IoT. Vyhněte se aktualizaci nebo odstranění výchozího prostředku BrokerAuthentication .
Na webu Azure Portal přejděte k vaší instanci ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte kartu Ověřování.
V seznamu zásad ověřování vyberte výchozí název zásady.
Pokud chcete přidat nové metody ověřování, vyberte Přidat metodu.
Tok ověřování
Pořadí zadaných metod ověřování určuje, jak zprostředkovatel MQTT ověřuje klienty. Zprostředkovatel MQTT se pokusí ověřit přihlašovací údaje klienta pomocí první zadané metody a iteruje zadanými metodami, dokud nenajde shodu nebo nedosáhne konce.
Pro každou metodu zprostředkovatel MQTT nejprve zkontroluje, jestli jsou přihlašovací údaje klienta pro danou metodu relevantní . Například ověřování SAT vyžaduje uživatelské jméno začínající K8S-SATa ověřování X.509 vyžaduje klientský certifikát. Pokud jsou přihlašovací údaje klienta relevantní, zprostředkovatel MQTT ověří, jestli jsou platné. Další informace najdete v části Konfigurace metody ověřování.
U vlastního ověřování zprostředkovatel MQTT zachází s chybou komunikace s vlastním ověřovacím serverem jako s přihlašovacími údaji, které nejsou relevantní. Toto chování umožňuje zprostředkovateli MQTT přejít k jiným metodám, pokud je vlastní ověřovací server nedostupný.
Tok ověřování končí v následujících případech:
- Jedna z těchto podmínek je pravdivá:
- Přihlašovací údaje klienta jsou relevantní a platné pro jednu z metod.
- Přihlašovací údaje klienta nejsou pro žádnou z metod relevantní.
- Přihlašovací údaje klienta jsou pro některou z metod relevantní, ale neplatné.
- Zprostředkovatel MQTT buď udělí nebo odmítne přístup k klientovi na základě výsledku ověřovacího toku.
Příklad:
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
Předchozí příklad určuje vlastní a SAT. Když se klient připojí, zprostředkovatel MQTT se pokusí ověřit klienta pomocí zadaných metod ve vlastním pořadí a pak SAT.
- Zprostředkovatel MQTT zkontroluje, jestli jsou přihlašovací údaje klienta platné pro vlastní ověřování. Vzhledem k tomu, že vlastní ověřování závisí na externím serveru k určení platnosti přihlašovacích údajů, zprostředkovatel považuje všechny přihlašovací údaje relevantní pro vlastní ověřování a předává je na vlastní ověřovací server.
- Pokud vlastní ověřovací server odpoví
PassneboFailvýsledek, tok ověřování skončí. Pokud ale vlastní ověřovací server není dostupný, vrátí se zprostředkovatel MQTT zpět ke zbývajícím zadaným metodám, přičemž sat je další. - Zprostředkovatel MQTT se pokusí ověřit přihlašovací údaje jako přihlašovací údaje SAT.
Pokud je vlastní ověřovací server nedostupný a všechny následné metody určují, že zadané přihlašovací údaje nejsou relevantní, zprostředkovatel odmítne připojení klienta.
Konfigurace metody ověřování
Do zásad ověřování můžete přidat metody ověřování, jako je X.509, SAT nebo vlastní.
Přidání metody ověřování do zásady:
Na webu Azure Portal přejděte k vaší instanci ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte kartu Ověřování.
Zvolte existující zásady ověřování nebo vytvořte novou.
Novou metodu přidáte výběrem možnosti Přidat metodu.
V rozevíracím seznamu zvolte typ metody a pak vyberte Přidat podrobnosti a nakonfigurujte metodu.
Další informace o jednotlivých možnostech ověřování najdete v dalších částech jednotlivých metod.
Další informace o povolení nastavení zabezpečení konfigurací služby Azure Key Vault a povolením identit úloh najdete v tématu Povolení nastavení zabezpečení v nasazení operací Azure IoT.
X.509
Tip
Kompletní příklad konfigurace ověřování X.509 najdete v tématu Kurz: Tls, ověřování klientů X.509 a autorizace řízení přístupu na základě atributů (ABAC).
S ověřováním X.509 používá zprostředkovatel MQTT k ověření klientských certifikátů důvěryhodný certifikát certifikační autority. Tato důvěryhodná certifikační autorita může být kořenovou nebo zprostředkující certifikační autoritou. Zprostředkovatel zkontroluje řetěz klientských certifikátů vůči certifikátu důvěryhodné certifikační autority. Pokud je řetěz platný, klient se ověří.
Pokud chcete použít ověřování X.509 s důvěryhodným certifikátem certifikační autority, musí být splněny následující požadavky:
- TLS: Vzhledem k tomu, že X.509 spoléhá na klientské certifikáty TLS, musí být pro porty s ověřováním X.509 povolený protokol TLS.
- Klíčové algoritmy: Podporují se klíče EC i RSA, ale všechny certifikáty v řetězu musí používat stejný algoritmus klíče.
- Formát: Certifikát certifikační autority musí být ve formátu PEM.
Tip
Formát PEM je běžný formát pro certifikáty a klíče. Soubory PEM jsou soubory ASCII s kódováním base64 s hlavičkami jako -----BEGIN CERTIFICATE----- a -----BEGIN EC PRIVATE KEY-----.
Pokud máte certifikát v jiném formátu, můžete ho převést na PEM pomocí OpenSSL. Další informace naleznete v tématu Jak převést certifikát do příslušného formátu.
Získání certifikátu důvěryhodné certifikační autority
V produkčním nastavení poskytuje certifikát certifikační autority infrastruktura veřejných klíčů (PKI) organizace nebo veřejná certifikační autorita.
Pro účely testování vytvořte certifikát certifikační autority podepsaný svým držitelem pomocí OpenSSL. Spuštěním následujícího příkazu vygenerujte certifikát certifikační autority podepsaný svým držitelem s klíčem RSA, rozlišujícím názvem CN=Contoso Root CA Certa platností 365 dnů:
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
Stejný příkaz s rozhraním příkazového řádku step, což je pohodlný nástroj pro správu certifikátů, je:
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
Tyto příkazy vytvoří certifikát ca.pem certifikační autority a privátní klíč ca-key.pem ve formátu PEM. Certifikát ca.pem certifikační autority je možné importovat do zprostředkovatele MQTT pro ověřování X.509.
Import certifikátu důvěryhodné certifikační autority
Pokud chcete začít s ověřováním X.509, naimportujte důvěryhodný certifikát certifikační autority do objektu azure-iot-operations ConfigMap v oboru názvů. Pokud chcete importovat certifikát důvěryhodné certifikační autority ca.pem do objektu ConfigMap s názvem client-ca, spusťte:
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
V tomto příkladu se certifikát certifikační autority naimportuje pod klíčem ca.pem. Zprostředkovatel MQTT důvěřuje všem certifikátům certifikační autority v objektu ConfigMap, takže název klíče může být cokoli.
Pokud chcete zkontrolovat, jestli je kořenový certifikát certifikační autority správně importovaný, spusťte kubectl describe configmappříkaz . Výsledek ukazuje stejné kódování base64 souboru certifikátu PEM.
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
====
Konfigurace metody ověřování X.509
Po importu certifikátu důvěryhodné certifikační autority povolte ověření klienta X.509 tak, že ho přidáte jako metodu ověřování do prostředku BrokerAuthentication . Ujistěte se, že je tento prostředek propojený s portem naslouchacího procesu s povoleným protokolem TLS.
Na webu Azure Portal přejděte k vaší instanci ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte kartu Ověřování.
Zvolte existující zásady ověřování nebo vytvořte novou.
Novou metodu přidáte výběrem možnosti Přidat metodu.
V rozevíracím seznamu zvolte typ metody X.509 a pak vyberte Přidat podrobnosti a nakonfigurujte metodu.
V podokně podrobností o ověřování X.509 zadejte název configmap certifikátu důvěryhodné certifikační autority pomocí formátu JSON.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Nahraďte
<TRUSTED_CA_CONFIGMAP>názvem objektu ConfigMap, který obsahuje certifikát důvěryhodné certifikační autority. Například"trustedClientCaCert": "client-ca".
Volitelně můžete přidat atributy autorizace pro klienty používající certifikáty X.509. Další informace najdete v tématu Atributy certifikátu pro autorizaci.
Chcete-li uložit změny, vyberte Použít .
Volitelné: Atributy certifikátu pro autorizaci
Atributy X.509 lze zadat v prostředku BrokerAuthentication pro autorizaci klientů na základě jejich vlastností certifikátu. Atributy jsou definovány v authorizationAttributes poli.
Příklad:
Na webu Azure Portal přidejte při konfiguraci metody ověřování X.509 atributy autorizace v podokně podrobností o ověřování X.509 ve formátu JSON.
{
"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"
}
}
}
}
V tomto příkladu každý klient, který má certifikát vydaný kořenovou certifikační autoritou s rozlišujícím názvem CN = Contoso Root CA Cert, OU = Engineering, C = US nebo zprostředkující certifikační autoritou s rozlišujícím názvem CN = Contoso Intermediate CA , obdrží uvedené atributy. Kromě toho klientský certifikát inteligentního ventilátoru přijímá atributy specifické pro něj.
Porovnávání atributů vždy začíná od klientského certifikátu typu list a pak pokračuje po řetězu. Přiřazení atributu se zastaví po první shodě. V předchozím příkladu, i když smart-fan má zprostředkující certifikát CN = Contoso Intermediate CA, nezískute přidružené atributy.
Autorizační pravidla lze použít pro klienty používající certifikáty X.509 s těmito atributy. Další informace najdete v tématu Autorizace klientů, kteří používají ověřování X.509.
Povolení ověřování X.509 pro port naslouchacího procesu
Po importu certifikátu důvěryhodné certifikační autority a konfiguraci prostředku BrokerAuthentication ho propojte s portem naslouchacího procesu s povoleným protokolem TLS. Tento krok je důležitý, protože ověřování X.509 spoléhá na ověřování klientských certifikátů na tls.
Pokud chcete získat port naslouchacího procesu s povoleným protokolem TLS, přečtěte si téma Povolení ruční správy certifikátů PROTOKOLU TLS pro port a povolení automatické správy certifikátů PROTOKOLU TLS pro port.
Poznámka:
Povolení protokolu TLS na portu naslouchacího procesu zprostředkovatele znamená, že zprostředkovatel používá pro šifrování TLS certifikát serveru. Když se klienti připojují k tomuto portu, musí důvěřovat certifikátu serveru tím, že mají certifikát certifikační autority, který ho podepsal ve svém úložišti důvěryhodnosti. Tento proces se označuje jako distribuce důvěryhodnosti nebo sdružování důvěryhodnosti. Je důležité pochopit rozdíl mezi ověřováním serveru a ověřováním klienta:
- Ověření klienta: Zprostředkovatel MQTT (server) kontroluje klientský certifikát vůči důvěryhodnému certifikátu certifikační autority zadanému v
trustedClientCaCertpoli pro ověřování klientů X.509. - Ověření serveru: Klienti (například mosquitto nebo MQTTX) kontrolují certifikát serveru zprostředkovatele MQTT vůči důvěryhodnému certifikátu certifikační autority ve svém úložišti důvěryhodnosti. Pro klienty mosquitto použijte
--cafileparametr k určení souboru certifikátu certifikační autority. Pro MQTTX přidejte certifikát certifikační autority do úložiště důvěryhodnosti v nastavení.
Po povolení ověřování X.509 zajistěte, aby klienti důvěřovali certifikátu serveru zprostředkovatele tím, že mají certifikát certifikační autority na straně serveru ve svém úložišti důvěryhodnosti. Nezaměňujte důvěryhodnost certifikátu certifikační autority na straně serveru s certifikátem certifikační autority na straně klienta, který se používá pro ověřování klienta zadaného trustedClientCaCert v poli.
Úplný příklad najdete v tématu Kurz: TLS, ověřování klientů X.509 a autorizace řízení přístupu na základě atributů (ABAC).
Připojení klienta mosquitto ke zprostředkovateli MQTT pomocí klientského certifikátu X.509
Klient, jako je mosquitto, potřebuje dva soubory, aby se mohl připojit ke zprostředkovateli MQTT pomocí protokolu TLS a ověřování klienta X.509.
- Parametr
--certurčuje soubor PEM klientského certifikátu. Tento soubor by měl obsahovat také všechny zprostředkující certifikáty, které zprostředkovateli MQTT pomůžou sestavit kompletní řetěz certifikátů. - Parametr
--keyurčuje soubor PEM privátního klíče klienta.
V případech, kdy zprostředkovatel MQTT používá certifikát certifikační autority podepsaný svým držitelem k vydání certifikátu serveru TLS, je potřeba parametr --cafile . Tento soubor obsahuje certifikát certifikační autority (označovaný také jako sada důvěryhodnosti), který klient mosquitto používá k ověření certifikátu serveru zprostředkovatele při připojování přes protokol TLS. Pokud je vystavitel certifikátu serveru zprostředkovatele MQTT součástí systémového kořenového úložiště (například známých veřejných certifikačních autorit), --cafile je možné parametr vynechat.
Příklad:
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
Principy toku ověřování klienta X.509 zprostředkovatele MQTT
Toto jsou kroky pro ověřování klientů:
- Pokud je zapnuté ověřování klientů X.509, musí připojení klienti předložit klientský certifikát a všechny zprostředkující certifikáty, aby zprostředkovatel MQTT vytvořil řetěz certifikátů root na jeden z nakonfigurovaných důvěryhodných certifikátů.
- Nástroj pro vyrovnávání zatížení směruje komunikaci na jednoho z front-endových zprostředkovatelů.
- Jakmile front-endový zprostředkovatel obdržel klientský certifikát, pokusí se vytvořit řetěz certifikátů, který je rootovaný na jednom z nakonfigurovaných certifikátů. Pokud front-endový zprostředkovatel úspěšně vytvořil řetěz a prezentovaný řetězec je ověřený, dokončí metodu handshake protokolu TLS. Připojovací klient dokáže odesílat pakety MQTT do front-endu prostřednictvím kanálu TLS.
- Kanál TLS je otevřený, ale ověřování nebo autorizace klienta ještě není dokončené.
- Klient pak odešle paket CONNECT do zprostředkovatele MQTT.
- Paket CONNECT se znovu směruje do front-endu.
- Front-end shromažďuje všechny přihlašovací údaje, které klient dosud zobrazil, jako jsou ověřovací data z paketu CONNECT, a řetěz klientských certifikátů prezentovaný během metody handshake protokolu TLS.
- Front-end tyto přihlašovací údaje odešle ověřovací službě. Ověřovací služba znovu zkontroluje řetěz certifikátů a shromažďuje názvy subjektu všech certifikátů v řetězu.
- Ověřovací služba používá nakonfigurovaná autorizační pravidla k určení atributů, které mají připojující se klienti. Tyto atributy určují, jaké operace může klient provést, včetně samotného paketu CONNECT.
- Ověřovací služba vrací rozhodnutí o front-endovém zprostředkovatele.
- Front-endový zprostředkovatel zná atributy klienta a jestli se může připojit. Pokud ano, připojení MQTT se dokončí a klient může dál odesílat a přijímat pakety MQTT podle autorizačních pravidel.
Tokeny účtu služby Kubernetes Service
Tokeny účtů služby Kubernetes Service (SAT) jsou webové tokeny JSON přidružené k účtům služby Kubernetes Service. Klienti prezentují SAT zprostředkovateli MQTT, aby se ověřili.
Zprostředkovatel MQTT používá tokeny účtu vázané služby, které jsou podrobně popsány v tématu Co uživatelé GKE potřebují vědět o příspěvku o nových tokenech účtu služby Kubernetes. Tady jsou nejdůležitější funkce z příspěvku:
Spuštěno v Kubernetes 1.13 a stává se výchozím formátem ve verzi 1.21, vázané tokeny řeší všechny omezené funkce starších tokenů a další:
- Samotné tokeny jsou těžší ukrást a zneužít; jsou vázané na čas, cílovou skupinu a objektově vázané.
- Přijímají standardizovaný formát: OpenID Connect (OIDC) s úplným zjišťováním OIDC, což usnadňuje poskytovatelům služeb jejich přijetí.
- Distribuují se do podů bezpečněji pomocí nového typu svazku s projektovaným kubeletem.
Zprostředkovatel ověřuje tokeny pomocí rozhraní API pro kontrolu tokenů Kubernetes. Povolte funkci Kubernetes TokenRequestProjection k určení audiences (výchozí od verze 1.21). Pokud tato funkce není povolená, nejde použít SAT.
Vytvoření obchodního vztahu služby
Pokud chcete vytvořit SAT, nejprve vytvořte účet služby. Následující příkaz vytvoří účet služby s názvem mqtt-client.
kubectl create serviceaccount mqtt-client -n azure-iot-operations
Volitelné: Přidání atributů pro autorizaci
Klienti, kteří se ověřují přes SAT, můžou mít volitelně přiřazené účty služeb s atributy, které se mají používat se zásadami autorizace. Aby se tyto poznámky odlišily od ostatních, začínají předponou aio-broker-auth/ .
Účet služby můžete komentovat pomocí kubectl annotate:
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
Nebo můžete přidat poznámky do souboru manifestu účtu služby:
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>
Další informace najdete v tématu Autorizace klientů, kteří používají tokeny účtů služby Kubernetes.
Povolení ověřování tokenu účtu služby (SAT)
authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat ServiceAccountToken jako platnou metodu ověřování. Určuje audiences seznam platných cílových skupin pro tokeny. Zvolte jedinečné hodnoty, které identifikují službu zprostředkovatele MQTT. Musíte zadat alespoň jednu cílovou skupinu a všechny SAT musí odpovídat jedné z určených cílových skupin.
- Na webu Azure Portal přejděte k vaší instanci ioT Operations.
- V části Součásti vyberte Zprostředkovatele MQTT.
- Vyberte kartu Ověřování.
- Zvolte existující zásady ověřování nebo vytvořte novou.
- Novou metodu přidáte výběrem možnosti Přidat metodu.
- V rozevíracím seznamu zvolte typ metody Kubernetes SAT a pak vyberte Přidat podrobnosti a nakonfigurujte metodu.
Testování ověřování SAT
Ověřování SAT používá pole rozšířeného ověřování MQTT v5. Klient musí nastavit rozšířenou metodu ověřování na K8S-SAT token a rozšířená ověřovací data na token.
Například použití mosquitto (některá pole vynechána pro stručnost):
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
<TOKEN> Tady je token účtu služby. Pokud chcete získat testovací token, spusťte:
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
Tady je název účtu služby, <SERVICE_ACCOUNT> který jste vytvořili, a <AUDIENCE> je jedním z cílových skupin nakonfigurovaných v prostředku BrokerAuthentication .
Příklad konfigurace podu Kubernetes tak, aby používal ověřování SAT, najdete v tématu Připojení k výchozímu naslouchacímu procesu v clusteru.
V konfiguraci podu serviceAccountName musí pole odpovídat účtu služby přidruženému k použitému tokenu a serviceAccountToken.audience pole musí být jedním z audiences nakonfigurovaných prostředků BrokerAuthentication .
Aktualizace tokenů účtu služby
Tokeny účtu služby jsou platné po omezenou dobu a konfigurují s expirationSeconds. Kubernetes ale token před vypršením platnosti automaticky aktualizuje. Token se aktualizuje na pozadí a klient nemusí dělat nic jiného, než aby ho znovu načítal.
Pokud je například klient podem, který používá token připojený jako svazek, například v testovacím příkladu ověřování SAT, je nejnovější token k dispozici ve stejné cestě /var/run/secrets/tokens/broker-sat. Při vytváření nového připojení může klient načíst nejnovější token a použít ho k ověření. Klient by měl mít také mechanismus pro zpracování neoprávněných chyb MQTT načtením nejnovějšího tokenu a opakováním připojení.
Vlastní ověřování
Rozšiřte ověřování klientů nad rámec zadaných metod ověřování pomocí vlastního ověřování. Je možné ji připojit, protože služba může být cokoli, pokud dodržuje rozhraní API.
Když se klient připojí ke zprostředkovateli MQTT s povoleným vlastním ověřováním, zprostředkuje požadavek HTTPS na vlastní ověřovací server s přihlašovacími údaji klienta. Server pak odpoví schválením nebo odepřením, včetně autorizačních atributů klienta.
Vytvoření vlastní ověřovací služby
Vlastní ověřovací server se implementuje a nasazuje odděleně od zprostředkovatele MQTT.
Ukázkový vlastní ověřovací server a pokyny jsou k dispozici na GitHubu. Tuto ukázku použijte jako šablonu a výchozí bod pro implementaci vlastní logiky ověřování.
rozhraní API
Rozhraní API mezi zprostředkovatelem MQTT a vlastním ověřovacím serverem se řídí specifikací rozhraní API pro vlastní ověřování. Specifikace OpenAPI je k dispozici na GitHubu.
Vyžaduje se šifrování HTTPS s protokolem TLS.
Zprostředkovatel MQTT odesílá požadavky obsahující citlivé přihlašovací údaje klienta na vlastní ověřovací server. Aby bylo možné tyto přihlašovací údaje chránit, musí být komunikace mezi zprostředkovatelem MQTT a vlastním ověřovacím serverem šifrovaná pomocí protokolu TLS.
Vlastní ověřovací server musí předložit certifikát serveru a zprostředkovatel MQTT musí mít certifikát důvěryhodné kořenové certifikační autority pro ověření certifikátu serveru. Volitelně může vlastní ověřovací server vyžadovat, aby zprostředkovatel MQTT předložil klientský certifikát, aby se ověřil sám.
Povolení vlastního ověřování pro naslouchací proces
authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat Custom jako platnou metodu ověřování. Pak zadejte parametry potřebné ke komunikaci s vlastním ověřovacím serverem.
Na webu Azure Portal přejděte k vaší instanci ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte kartu Ověřování.
Zvolte existující zásady ověřování nebo vytvořte novou.
Novou metodu přidáte výběrem možnosti Přidat metodu.
V rozevíracím seznamu zvolte typ metody Vlastní a pak vyberte Přidat podrobnosti a nakonfigurujte metodu.
Zakázání ověřování
Pro účely testování můžete zakázat ověřování pro port naslouchacího procesu zprostředkovatele. Zakázání ověřování se nedoporučuje pro produkční prostředí.
- Na webu Azure Portal přejděte k vaší instanci ioT Operations.
- V části Součásti vyberte Zprostředkovatele MQTT.
- Ze seznamu vyberte naslouchací proces zprostředkovatele, který chcete upravit.
- Na portu, který chcete zakázat ověřování, vyberte v rozevíracím seznamu Ověřování možnost Žádné .
Klienti se odpojí po vypršení platnosti přihlašovacích údajů.
Zprostředkovatel MQTT odpojí klienty, když jejich přihlašovací údaje vyprší. Odpojení po vypršení platnosti přihlašovacích údajů platí pro všechny klienty, kteří se připojují k front-endům zprostředkovatele MQTT, včetně:
- Klienti ověření pomocí SAT se odpojí, když vyprší jejich platnost SAT.
- Klienti ověření pomocí X.509 se odpojí, když jejich klientský certifikát vyprší
- Klienti ověření pomocí vlastního ověřování se odpojí na základě doby vypršení platnosti vrácené z vlastního ověřovacího serveru.
Při odpojení je síťové připojení klienta uzavřeno. Klient neobdrží paket MQTT DISCONNECT, ale zprostředkovatel zaznamená zprávu, že klienta odpojil.
Klienti MQTT v5 ověření pomocí SAT a vlastního ověřování se můžou znovu ověřit pomocí nových přihlašovacích údajů před vypršením jejich počátečních přihlašovacích údajů. Klienti X.509 nemohou znovu ověřit a musí znovu navázat připojení, protože ověřování probíhá ve vrstvě TLS.
Klienti mohou znovu provést ověření odesláním paketu MQTT v5 AUTH s důvodem ReAuth.
Klienti SAT odesílají klienta AUTH s poli method: K8S-SAT, data: <token>.
Vlastní klienti ověřování nastavují metodu a datové pole podle požadavků vlastního ověřovacího serveru.
Úspěšné opětovné ověření aktualizuje vypršení platnosti přihlašovacích údajů klienta časem vypršení platnosti jeho nových přihlašovacích údajů a zprostředkovatel odpoví paketem Success AUTH. Neúspěšné ověřování kvůli přechodným problémům, jako je nedostupnost vlastního ověřovacího serveru, způsobí, že zprostředkovatel odpoví paketem AUTH typu ContinueAuthentication . Klient se může později zkusit znovu. Jiná selhání ověřování způsobují, že zprostředkovatel odešle paket DISCONNECT a zavře síťové připojení klienta.