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. 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ý prostředek BrokerListener může mít více portů. Každý port můžete propojit s prostředkem BrokerAuthentication.
- Každý prostředek 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.
Důležité
Metoda ověřování SAT ve výchozím prostředku BrokerAuthentication je nutná pro správné fungování komponent v operacích IoT. Vyhněte se aktualizaci nebo odstranění výchozího prostředku BrokerAuthentication.
Na webu Azure Portal přejděte do vaší instance 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 pak ověří, jestli jsou platné. Další informace najdete v části Konfigurace metody ověřování.
U vlastního ověřování zprostředkovatel MQTT považuje chybu při komunikaci 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 custom a SAT. Když se klient připojí, zprostředkovatel MQTT se pokusí ověřit klienta pomocí zadaných metod v pořadí custom 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á je vlastnímu ověřovacímu serveru.
- Pokud vlastní ověřovací server odpoví
PassneboFailvýsledkem, tok ověřování skončí. Pokud vlastní ověřovací server není k dispozici, zprostředkovatel MQTT se vrá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 vlastní ověřovací server není dostupný 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 do vaší instance 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 tom, jak povolit zabezpečená nastavení konfigurací instance 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 certifikát důvěryhodné certifikační autority (CA) k ověření klientských certifikátů. 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íte splnit následující požadavky:
- Protokol TLS (Transport Layer Security): Vzhledem k tomu, že X.509 využívá klientské certifikáty TLS, musí být pro porty povolené ověřování X.509.
- 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 CA musí být ve formátu PEM (Privacy-Enhanced Mail).
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 Převod certifikátu 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.pemcertifikační autority a privátní klíč ca-key.pemve formátu PEM. Certifikát ca.pem certifikační autority můžete 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 pro název klíče můžete použít cokoli.
Pokud chcete zkontrolovat, jestli je kořenový certifikát certifikační autority správně importovaný, spusťte kubectl describe configmappříkaz . Výsledkem je 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 do vaší instance 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 . Pak vyberte Přidat podrobnosti a nakonfigurujte metodu.
V podokně podrobností o ověřování X.509 zadejte název objektu ConfigMap 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 použijte"trustedClientCaCert": "client-ca".
Volitelně můžete přidat atributy autorizace pro klienty pomocí certifikátů 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
V prostředku BrokerAuthentication můžete zadat atributy X.509 pro autorizaci klientů na základě jejich vlastností certifikátu. Atributy jsou definovány v authorizationAttributes poli.
Příklad:
Když na webu Azure Portal nakonfigurujete metodu ověřování X.509, přidejte 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 můžete použít pro klienty pomocí certifikátů 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 klienta a ověřováním serveru:
-
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í klientů 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ěryhodných certifikátů), který klient Mosquitto používá k ověření certifikátu serveru zprostředkovatele při připojení 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 může být parametr vynechán.
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
Při ověřování klientů postupujte takto:
- 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 s jedním 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ží 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ě sestaví řetězec a 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í klienti. Tyto atributy určují, jaké operace může klient spustit, včetně samotného paketu CONNECT.
- Ověřovací služba vrátí rozhodnutí front-endového 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
SAT Kubernetes jsou webové tokeny JSON přidružené k účtům služby Kubernetes. Klienti prezentují SAT zprostředkovateli MQTT, aby se ověřili.
Zprostředkovatel MQTT používá tokeny účtu vázané služby, které jsou 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 hlavní funkce z příspěvku:
Vázané tokeny spuštěné v Kubernetes 1.13 a staly se výchozím formátem ve verzi 1.21. Vázané tokeny řeší všechny omezené funkce starších tokenů a další:
- Tokeny jsou těžké ukrást a zneužít. Jsou vázané na čas, cílové skupiny a objektově vázané.
- Přijímají standardizovaný formát. OpenID Connect (OIDC) s úplným zjišťováním OIDC usnadňuje poskytovatelům služeb jejich přijetí.
- Distribuují se bezpečně do podů pomocí nového typu svazku projektu Kubelet.
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á, nemůžete 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 účtu služby Kubernetes.
Povolení ověřování SAT
authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat ServiceAccountToken jako platnou metodu ověřování. Parametr audiences určuje 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 do vaší instance 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 . 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.
Použijte například 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. Pole serviceAccountToken.audience 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. Když klient vytvoří nové 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 připojitelný, 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 k ověření.
Povolení vlastního ověřování pro naslouchací proces
Upravte nastavení metod ověřování v prostředku BrokerAuthentication tak, aby bylo možné zadat vlastní 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 do vaší instance 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í . 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. Nedoporučujeme zakázat ověřování pro produkční prostředí.
- Na webu Azure Portal přejděte do vaší instance ioT Operations.
- V části Součásti vyberte Zprostředkovatele MQTT.
- Ze seznamu vyberte naslouchací proces zprostředkovatele, který chcete upravit.
- Na portu, na kterém 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, například:
- 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 nemůžou znovu ověřit připojení a musí připojení znovu publikovat, 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 a 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 s časem vypršení platnosti jeho nových přihlašovacích údajů. Zprostředkovatel odpoví paketem Success AUTH. Neúspěšné ověřování kvůli přechodným problémům, jako je nedostupný vlastní ověřovací server, způsobí, že zprostředkovatel odpoví paketem ContinueAuthentication AUTH. 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.