Configurer l’authentification de MQTT broker
Important
Cette page inclut des instructions pour la gestion des composants Azure IoT Operations à l’aide des manifestes de déploiement Kubernetes, qui sont en version préliminaire. Cette fonctionnalité est fournie avec plusieurs limitations et ne doit pas être utilisée pour les charges de travail de production.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
L’Agent MQTT prend en charge plusieurs méthodes d’authentification pour les clients, et vous pouvez configurer chaque port écouteur pour qu’il ait ses propres paramètres d’authentification avec une ressource BrokerAuthentication. Pour obtenir la liste des paramètres disponibles, consultez la référence de l’API d’authentification Broker.
Lier BrokerListener et BrokerAuthentication
Les règles suivantes s’appliquent à la relation entre les ressources BrokerListener et BrokerAuthentication :
- Chaque BrokerListener peut avoir plusieurs ports. Chaque port peut être lié à une ressource BrokerAuthentication.
- Chaque BrokerAuthentication peut prendre en charge plusieurs méthodes d’authentification à la fois.
- L’authentification des ports qui ne lient pas des ressources BrokerAuthentication est désactivée.
Pour lier un port BrokerListener à une ressource BrokerAuthentication, spécifiez le champ authenticationRef dans le paramètre ports de la ressource BrokerListener. Pour en savoir plus, consultez Ressource BrokerListener.
Ressource BrokerAuthentication par défaut
Opérations Azure IoT déploie une ressource BrokerAuthentication par défaut nommée default liée à l’écouteur par défaut dans l’espace de noms azure-iot-operations. Elle utilise uniquement les jetons de compte Kubernetes Service (SAT) pour l’authentification.
Important
La méthode d’authentification du jeton de compte de service (SAT) dans la ressource BrokerAuthentication par défaut est requise pour que les composants des opérations Azure IoT fonctionnent correctement. Évitez de mettre à jour ou de supprimer la ressource BrokerAuthentication par défaut.
Dans le portail Azure, accédez à votre instance Opérations IoT.
Sous Composants, sélectionnez Agent MQTT.
Sélectionnez l’onglet Authentification.
Dans la liste des stratégies d’authentification, sélectionnez le nom de la stratégie par défaut.
Pour ajouter de nouvelles méthodes d’authentification, sélectionnez Ajouter une méthode.
Flux d’authentification
L’ordre des méthodes d’authentification spécifiées dans le tableau détermine comment l’Agent MQTT authentifie les clients. L’Agent MQTT tente d’authentifier les informations d’identification du client en utilisant la première méthode spécifiée, et parcourt les méthodes spécifiées jusqu’à ce qu’il trouve une correspondance ou atteigne la fin.
Pour chaque méthode, MQTT broker vérifie d’abord si les informations d’identification du client sont pertinentes pour cette méthode. Par exemple, l’authentification SAT nécessite un nom d’utilisateur commençant par K8S-SAT, et l’authentification X.509 nécessite un certificat client. Si les informations d’identification du client sont pertinentes, MQTT broker vérifie ensuite si elles sont valides. Pour plus d’informations, consultez la section Configurer la méthode d’authentification.
Pour l’authentification personnalisée, MQTT broker traite l’échec de la communication avec le serveur d’authentification personnalisé comme des informations d’identification non pertinentes. Ce comportement permet à l’Agent MQTT de revenir à d’autres méthodes si le serveur d’authentification personnalisée est inaccessible.
Le flux d’authentification se termine lorsque :
- L’une de ces conditions est vraie :
- Les informations d’identification du client sont pertinentes et valides pour l’une des méthodes.
- Les informations d’identification du client ne sont pertinentes pour aucune des méthodes.
- Les informations d’identification du client sont pertinentes mais non valides pour l’une des méthodes.
- MQTT broker accorde ou refuse l’accès au client en fonction du résultat du flux d’authentification.
Par exemple :
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
L’exemple précédent spécifie Custom et SAT. Lorsqu’un client se connecte, l’Agent MQTT tente d’authentifier le client en utilisant les méthodes spécifiées dans l’ordre Personnalisée, puis SAT.
- MQTT broker vérifie si les informations d’identification du client sont valides pour l’authentification personnalisée. Étant donné que l’authentification personnalisée s’appuie sur un serveur externe pour déterminer la validité des informations d’identification, le répartiteur considère toutes les informations d’identification pertinentes pour l’authentification personnalisée et les transfère au serveur d’authentification personnalisé.
- Si le serveur d’authentification personnalisé répond avec le résultat
PassouFail, le flux d’authentification se termine. Toutefois, si le serveur d’authentification personnalisé n’est pas disponible, MQTT broker revient aux méthodes spécifiées restantes, la méthode SAT étant la suivante. - MQTT broker tente d’authentifier les informations d’identification en tant qu’informations d’identification SAT.
Si le serveur d’authentification personnalisée n’est pas disponible et que toutes les méthodes suivantes ont déterminé que les informations d’identification fournies ne sont pas pertinentes, alors le répartiteur refuse la connexion cliente.
Configurer la méthode d'authentification
Vous pouvez ajouter des méthodes d’authentification telles que X.509, SAT ou personnalisées aux stratégies d’authentification.
Pour ajouter une méthode d’authentification à une stratégie :
Dans le portail Azure, accédez à votre instance Opérations IoT.
Sous Composants, sélectionnez Agent MQTT.
Sélectionnez l’onglet Authentification.
Choisissez une stratégie d’authentification existante ou créez-en une.
Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
Choisissez le type de méthode dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.
Pour en savoir plus sur chacune des options d’authentification, consultez les sections suivantes pour chaque méthode.
Pour plus d’informations sur l’activation des paramètres sécurisés en configurant un Azure Key Vault et en activant des identités de charge de travail, consultez Activer les paramètres sécurisés dans le déploiement Opérations Azure IoT.
X.509
Conseil
Pour obtenir un exemple de la configuration de bout en bout de l’authentification X.509, consultez Tutoriel : TLS, authentification du client X.509 et autorisation de contrôle d’accès en fonction des attributs (ABAC).
Avec l’authentification X.509, l’agent MQTT utilise un certificat d’autorité de certification approuvé pour valider les certificats clients. Cette autorité de certification approuvée peut être une autorité de certification racine ou intermédiaire. L’agent vérifie la chaîne de certificat client sur le certificat d’autorité de certification approuvé. Si la chaîne est valide, le client est authentifié.
Pour utiliser l’authentification X.509 avec un certificat d’autorité de certification approuvé, les conditions suivantes doivent être remplies :
- TLS : étant donné que X.509 s’appuie sur des certificats clients TLS, TLS doit être activé pour les ports utilisant l’authentification X.509.
- Algorithmes clés : les clés EC et RSA sont prises en charge, mais tous les certificats de la chaîne doivent utiliser le même algorithme de clé.
- Format : le certificat d’autorité de certification doit être au format PEM.
Conseil
Le format PEM est un format couramment utilisé pour les certificats et les clés. Les fichiers PEM sont des fichiers ASCII encodés en base64 avec des en-têtes tels que -----BEGIN CERTIFICATE----- et -----BEGIN EC PRIVATE KEY-----.
Si vous utilisez un certificat dans un autre format, vous pouvez aussi le convertir au format PEM avec OpenSSL. Pour plus d’informations, consultez Convertir un certificat au format approprié.
Obtenir un certificat d’autorité de certification approuvé
Dans une configuration de production, le certificat d’autorité de certification est fourni par l’infrastructure à clé publique (PKI) d’une organisation ou une autorité de certification publique.
Pour les tests, créez un certificat d’autorité de certification auto-signé avec OpenSSL. Par exemple, exécutez la commande suivante pour générer un certificat d’autorité de certification auto-signé avec une clé RSA, un nom unique CN=Contoso Root CA Cert et une validité de 365 jours :
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
La même commande avec l’étape CLI, qui est un outil pratique pour la gestion des certificats, est la suivante :
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
Ces commandes créent un certificat d’autorité de certification ca.pem et une clé ca-key.pem privée au format PEM. Le certificat d’autorité de certification ca.pem peut être importé dans l’agent MQTT pour l’authentification X.509.
Importer un certificat d'Autorité de certification approuvée
Pour commencer à utiliser l’authentification X.509, importez le certificat d’autorité de certification approuvé dans un ConfigMap dans l’espace de noms azure-iot-operations. Pour importer un certificat d’autorité de certification approuvé ca.pem dans un ConfigMap nommé client-ca, exécutez :
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
Dans cet exemple, le certificat d’autorité de certification est importé sous la clé ca.pem. L’Agent MQTT approuve tous les certificats d’autorité de certification dans la ConfigMap, le nom de la clé n’est donc pas défini.
Pour vérifier que le certificat d’autorité de certification racine est correctement importé, exécutez kubectl describe configmap. Le résultat montre le même encodage base64 du fichier de certificat 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
====
Configurer la méthode d’authentification X.509
Une fois le certificat d’autorité de certification approuvé importé, activez l’authentification client X.509 en l’ajoutant en tant que méthode d’authentification dans une ressource BrokerAuthentication. Vérifiez que cette ressource est bien liée à un port d’écouteur compatible avec TLS.
Dans le portail Azure, accédez à votre instance Opérations IoT.
Sous Composants, sélectionnez Agent MQTT.
Sélectionnez l’onglet Authentification.
Choisissez une stratégie d’authentification existante ou créez-en une.
Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
Choisissez le type de méthode X.509 dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.
Dans le volet détails de l’authentification X.509, spécifiez le nom ConfigMap du certificat d’autorité de certification approuvé au format JSON.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Remplacez
<TRUSTED_CA_CONFIGMAP>par le nom du ConfigMap qui contient le certificat d’autorité de certification approuvé. Par exemple :"trustedClientCaCert": "client-ca".
Si vous le souhaitez, ajoutez des attributs d’autorisation pour les clients utilisant des certificats X.509. Pour plus d’informations, consultez Attributs de certificat pour l’autorisation.
Cliquez sur Appliquer pour enregistrer les modifications.
Facultatif : attributs de certificat pour l’autorisation
Les attributs X.509 peuvent être spécifiés dans la ressource BrokerAuthentication pour autoriser les clients en fonction de leurs propriétés de certificat. Les attributs sont définis dans le champ authorizationAttributes.
Par exemple :
Dans le portail Microsoft Azure, lors de la configuration de la méthode d’authentification X.509, ajoutez les attributs d’autorisation dans le volet d’informations d’authentification X.509 au format 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"
}
}
}
}
Dans cet exemple, chaque client disposant d’un certificat émis par l’autorité de certification racine portant un nom unique CN = Contoso Root CA Cert, OU = Engineering, C = US ou l’autorité de certification intermédiaire portant un nom unique CN = Contoso Intermediate CA reçoit les attributs répertoriés. En outre, le certificat client smart fan reçoit des attributs spécifiques à celui-ci.
La correspondance pour les attributs commence toujours à partir du certificat client de nœud terminal, puis est acheminée le long de la chaîne. L’affectation d’attributs s’arrête après la première correspondance. Dans l’exemple précédent, même si smart-fan a le certificat intermédiaire CN = Contoso Intermediate CA, il n’obtient pas les attributs associés.
Des règles d’autorisation peuvent être appliquées aux clients utilisant des certificats X.509 avec ces attributs. Pour plus d’informations, consultez Autoriser les clients qui utilisent l’authentification X.509.
Activer l’authentification X.509 pour un port d’écouteur
Après avoir importé le certificat d’autorité de certification approuvé et configuré la ressource BrokerAuthentication, liez-la à un port d’écouteur compatible avec TLS. Cette étape est importante, car l’authentification X.509 s’appuie sur TLS pour la validation des certificats clients.
Pour obtenir un port d’écouteur compatible avec TLS, consultez Activer la gestion manuelle des certificats TLS pour un port et Activer la gestion automatique des certificats TLS pour un port.
Remarque
L’activation de TLS sur un port d’écouteur d’agent signifie que l’agent utilise un certificat de serveur pour le chiffrement TLS. Lorsque les clients se connectent à ce port, ils doivent approuver le certificat de serveur en ayant le certificat d’autorité de certification qui l’a signée dans leur magasin de confiance. Ce processus est appelé distribution de confiance ou groupement de confiance. Il est important de comprendre la différence entre la validation par le serveur et la validation par le client :
- Validation par le client : l’agent MQTT (serveur) vérifie le certificat client par rapport au certificat d’autorité de certification approuvé spécifié dans le champ
trustedClientCaCertpour l’authentification client X.509. - Validation par le serveur : les clients (comme mosquitto ou MQTTX) vérifient le certificat de serveur de l’agent MQTT sur le certificat d’autorité de certification approuvé dans leur magasin de confiance. Pour les clients mosquitto, utilisez le paramètre
--cafilepour spécifier le fichier de certificat d’autorité de certification. Pour MQTTX, ajoutez le certificat d’autorité de certification au magasin de confiance dans les paramètres.
Après avoir activé l’authentification X.509, assurez-vous que les clients font confiance au certificat de serveur de l’agent en ayant le certificat d’autorité de certification côté serveur dans leur magasin de confiance. Ne confondez pas l’approbation du certificat d’autorité de certification côté serveur avec le certificat d’autorité de certification côté client utilisé pour l’authentification client spécifiée dans le champ trustedClientCaCert.
Pour voir un exemple complet, consultez Tutoriel : TLS, authentification client X.509 et autorisation de contrôle d'accès basé sur les attributs (ABAC).
Connecter le client mosquitto à MQTT broker avec un certificat client X.509
Un client comme mosquitto a besoin de deux fichiers pour pouvoir se connecter à l’Agent MQTT avec l’authentification du client TLS et X.509.
- Le paramètre
--certspécifie le fichier PEM du certificat client. Ce fichier doit également inclure tous les certificats intermédiaires pour aider l’Agent MQTT à générer la chaîne de certificats complète. - Le paramètre
--keyspécifie le fichier PEM de clé privée du client.
Dans les cas où l’Agent MQTT utilise un certificat d’autorité de certification auto-signé pour émettre son certificat de serveur TLS, le paramètre --cafile est nécessaire. Ce fichier contient le certificat d’autorité de certification (aussi appelé groupe de confiance) que le client mosquitto utilise pour valider le certificat de serveur de l’agent lors de la connexion via TLS. Si l’émetteur du certificat de serveur de l’Agent MQTT fait partie du magasin racine système (par exemple, les autorités de certification publiques connues), le paramètre --cafile peut être omis.
Par exemple :
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
Comprendre le flux d’authentification du client X.509 MQTT broker
Voici les étapes du flux d’authentification client :
- Lorsque l’authentification client X.509 est activée, les clients se connectant doivent présenter leur certificat client et tous les certificats intermédiaires pour permettre à l’Agent MQTT de générer une chaîne de certificats enracinée dans l’un de ses certificats approuvés configurés.
- L’équilibreur de charge dirige la communication vers l’un des répartiteurs front-end.
- Une fois que le répartiteur front-end a reçu le certificat client, il tente de générer une chaîne de certificats qui est enracinée dans l’un des certificats configurés. Si le répartiteur front-end a correctement créé une chaîne et que la chaîne présentée est vérifiée, il termine l’établissement d’une liaison TLS. Le client qui se connecte est en mesure d’envoyer des paquets MQTT au front-end via le canal TLS.
- Le canal TLS est ouvert, mais l’authentification ou l’autorisation du client n’est pas encore terminée.
- Le client envoie ensuite un paquet CONNECT à MQTT broker.
- Le paquet CONNECT est routé à nouveau vers le serveur front-end.
- Le serveur frontal collecte toutes les informations d’identification présentées par le client jusqu’à présent, telles que les données d’authentification à partir du paquet CONNECT et la chaîne de certificats client présentée lors de l’établissement d’une liaison TLS.
- Le serveur front-end envoie ces informations d’identification au service d’authentification. Le service d’authentification vérifie à nouveau la chaîne de certificats et collecte les noms d’objet de tous les certificats de la chaîne.
- Le service d’authentification utilise ses règles d’autorisation configurées pour déterminer les attributs dont disposent les clients qui se connectent. Ces attributs déterminent les opérations que le client peut exécuter, y compris le paquet CONNECT lui-même.
- Le service d’authentification retourne la décision au répartiteur front-end.
- Le répartiteur front-end connaît les attributs du client et s’il est autorisé à se connecter. Si c’est le cas, alors la connexion MQTT est achevée et le client peut continuer à envoyer et recevoir des paquets MQTT déterminés par ses règles d’autorisation.
Jetons de compte de service Kubernetes
Les jetons de compte de service (SAT) Kubernetes sont des JSON Web Tokens associés à des comptes de service Kubernetes. Les clients présentent des SAT à MQTT broker pour s’authentifier eux-mêmes.
MQTT broker utilise des jetons de compte de service liés qui sont détaillés dans le billet Ce que les utilisateurs de GKE doivent savoir sur les nouveaux jetons de compte de service Kubernetes. Voici les principales fonctionnalités de la publication :
Lancés dans Kubernetes 1.13 et devenus le format par défaut dans la version 1.21, les jetons liés répondent à toutes les fonctionnalités limitées des jetons traditionnels, et plus encore :
- Les jetons eux-mêmes sont plus difficiles à voler et à utiliser à mauvais escient. Ils sont limités dans le temps, limités à l’audience et limités à l’objet.
- Ils adoptent un format standardisé : OpenID Connect (OIDC), avec détection OIDC complète, ce qui permet aux fournisseurs de services de les accepter plus facilement.
- Ils sont distribués aux pods de manière plus sécurisée, à l’aide d’un nouveau type de volume projeté Kubelet.
Le répartiteur vérifie les jetons à l’aide de l’API de révision des jetons Kubernetes. Activez la fonctionnalité TokenRequestProjection Kubernetes pour spécifier audiences (par défaut depuis la version 1.21). Si cette fonctionnalité n’est pas activée, les SAT ne peuvent pas être utilisés.
Création d’un compte de service
Pour créer des SAT, commencez par créer un compte de service. La commande suivante crée un compte de service appelé mqtt-client.
kubectl create serviceaccount mqtt-client -n azure-iot-operations
Facultatif : ajouter des attributs pour l’autorisation
Les clients qui s’authentifient via SAT peuvent éventuellement avoir leurs comptes de service annotés avec des attributs à utiliser avec les stratégies d’autorisation. Pour distinguer ces annotations des autres, elles commencent par le préfixe aio-broker-auth/.
Vous pouvez annoter un compte de service à l’aide de kubectl annotate :
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
Vous pouvez également ajouter les annotations au fichier manifeste du compte de service :
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>
Pour plus d’informations, consultez Autoriser les clients qui utilisent des jetons de compte de service Kubernetes.
Activer l’authentification par jeton de compte de service (SAT)
Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier ServiceAccountToken comme méthode d’authentification valide. Le audiences spécifie la liste des audiences valides pour les jetons. Choisissez des valeurs uniques qui identifient le service MQTT broker. Vous devez spécifier au moins une audience, et tous les SAT doivent correspondre à l’une des audiences spécifiées.
- Dans le portail Azure, accédez à votre instance Opérations IoT.
- Sous Composants, sélectionnez Agent MQTT.
- Sélectionnez l’onglet Authentification.
- Choisissez une stratégie d’authentification existante ou créez-en une.
- Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
- Choisissez le type de méthode SAT Kubernetes dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.
Tester l’authentification SAT
L’authentification SAT utilise les champs d’authentification améliorés MQTT v5. La méthode d’authentification améliorée sur K8S-SAT et les données d’authentification améliorées sur le jeton doivent être définies par le client.
Par exemple, en utilisant mosquitto (certains champs omis pour rester concis) :
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
Ici, <TOKEN> est le jeton de compte de service. Pour obtenir un jeton de test, exécutez :
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
Ici, <SERVICE_ACCOUNT> est le nom du compte de service que vous avez créé et <AUDIENCE> est l’une des audiences configurées dans la ressource BrokerAuthentication.
Pour obtenir un exemple de configuration d’un pod Kubernetes pour qu’il utilise l’authentification SAT, consultez Se connecter à l’écouteur par défaut à l’intérieur du cluster.
Dans la configuration du pod, le champ serviceAccountName doit correspondre au compte de service associé au jeton utilisé, et le champ serviceAccountToken.audience doit être l’une des audiences configurées dans la ressource BrokerAuthentication.
Actualiser les jetons de compte de service
Les jetons de compte de service sont valides pendant une durée limitée et configurés avec expirationSeconds. Toutefois, Kubernetes actualise automatiquement le jeton avant son expiration. Le jeton est actualisé en arrière-plan et le client a seulement besoin de le récupérer à nouveau.
Par exemple, si le client est un pod qui utilise le jeton monté en tant que volume, comme dans l’exemple tester l’authentification SAT, le dernier jeton est disponible au même chemin d’accès /var/run/secrets/tokens/broker-sat. Lorsque vous effectuez une nouvelle connexion, le client peut récupérer le dernier jeton et l’utiliser pour s’authentifier. Le client doit également disposer d’un mécanisme permettant de gérer les erreurs non autorisées MQTT en récupérant le dernier jeton et en réessayant la connexion.
Authentification personnalisée
Étendez l’authentification du client au-delà des méthodes d’authentification fournies avec l’authentification personnalisée. Le service est enfichable car il peut être n’importe quoi tant qu’il respecte l’API.
Lorsqu’un client se connecte à l’agent MQTT avec l’authentification personnalisée activée, l’agent envoie une requête HTTPS à un serveur d’authentification personnalisé avec les informations d’identification du client. Le serveur répond ensuite par approbation ou déni, y compris les attributs d’autorisation du client.
Créer un service d’authentification personnalisé
Le serveur d’authentification personnalisé est implémenté et déployé séparément de MQTT broker.
Un exemple de serveur d’authentification personnalisé et des instructions sont disponibles sur GitHub. Utilisez cet exemple en tant que modèle pour implémenter votre propre logique d’authentification personnalisée.
API
L’API entre MQTT broker et le serveur d’authentification personnalisé suit la spécification de l’API pour l’authentification personnalisée. La spécification OpenAPI est disponible sur GitHub.
HTTPS avec chiffrement TLS requis
MQTT broker envoie des requêtes contenant des informations d’identification client sensibles au serveur d’authentification personnalisée. Pour protéger ces informations d’identification, la communication entre MQTT broker et le serveur d’authentification personnalisée doit être chiffrée avec TLS.
Le serveur d’authentification personnalisée doit présenter un certificat de serveur, et MQTT broker doit disposer d’un certificat d’autorité de certification racine approuvé pour valider le certificat de serveur. Si vous le souhaitez, le serveur d’authentification personnalisée peut exiger que MQTT broker présente un certificat client pour s’authentifier lui-même.
Activer l’authentification personnalisée pour un écouteur
Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier Custom comme méthode d’authentification valide. Ensuite, spécifiez les paramètres nécessaires pour communiquer avec un serveur d’authentification personnalisé.
Dans le portail Azure, accédez à votre instance Opérations IoT.
Sous Composants, sélectionnez Agent MQTT.
Sélectionnez l’onglet Authentification.
Choisissez une stratégie d’authentification existante ou créez-en une.
Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
Choisissez le type de méthode Personnalisé dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.
Désactiver l’authentification
Pour les tests, vous pouvez désactiver l’authentification pour un port d’écouteur d’agent. La désactivation de l’authentification n’est pas recommandée pour les environnements de production.
- Dans le portail Azure, accédez à votre instance Opérations IoT.
- Sous Composants, sélectionnez Agent MQTT.
- Sélectionnez l’écouteur d’agent que vous souhaitez modifier dans la liste.
- Sur le port pour lequel vous souhaitez désactiver l’authentification, sélectionnez Aucune dans la liste déroulante d’authentification.
Déconnexion des clients après expiration des informations d’identification
MQTT broker déconnecte les clients à l’expiration de leurs informations d’identification. La déconnexion après l’expiration des informations d’identification s’applique à tous les clients qui se connectent aux front-ends MQTT broker, notamment :
- Les clients authentifiés avec des SAT se déconnectent lorsque leur SAT expire
- Les clients authentifiés avec X.509 se déconnectent lorsque leur certificat client expire
- Les clients authentifiés avec une authentification personnalisée se déconnectent en fonction de l’heure d’expiration retournée par le serveur d’authentification personnalisée.
Lors de la déconnexion, la connexion réseau du client est fermée. Le client ne reçoit pas de paquet MQTT DISCONNECT, mais l’agent enregistre un message indiquant qu’il a déconnecté le client.
Les clients MQTT v5 authentifiés avec des SAT et une authentification personnalisée peuvent se réauthentifier avec de nouvelles informations d’identification avant l’expiration de leurs informations d’identification initiales. Les clients X.509 ne peuvent pas se réauthentifier et doivent rétablir la connexion, car l’authentification est effectuée au niveau de la couche TLS.
Les clients peuvent se réauthentifier en envoyant un paquet AUTH MQTT v5 avec un motif ReAuth.
Les clients SAT envoient un client AUTH avec les champs method: K8S-SAT, data: <token>.
Les clients d’authentification personnalisée définissent la méthode et le champ de données en fonction des exigences du serveur d’authentification personnalisée.
La réauthentification réussie met à jour l’expiration des informations d’identification du client avec l’heure d’expiration de ses nouvelles informations d’identification, et le répartiteur répond avec un paquet Success AUTH. L’échec de l’authentification en raison de problèmes temporaires, comme l’indisponibilité du serveur d’authentification personnalisée, entraîne une réponse du répartiteur avec un paquet AUTH ContinueAuthentication. Le client peut réessayer ultérieurement. Les autres échecs d’authentification entraînent l’envoi d’un paquet DISCONNECT par le répartiteur, et la fermeture de la connexion réseau du client.