Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Authentification et autorisation personnalisées AWS IoT Core vous permet de définir des autorisateurs personnalisés afin que vous puissiez gérer vous-même l'authentification et l'autorisation de vos clients. Cela est utile lorsque vous devez utiliser des mécanismes d'authentification autres que ceux pris en charge de AWS IoT Core manière native. (Pour plus d'informations sur les mécanismes pris en charge de manière native, consultez [Authentification client](client-authentication.md)).  Par exemple, si vous migrez des appareils existants sur le terrain AWS IoT Core et que ces appareils utilisent un jeton porteur personnalisé ou un nom d'utilisateur et un mot de passe MQTT pour s'authentifier, vous pouvez les migrer vers ces appareils AWS IoT Core sans avoir à leur fournir de nouvelles identités. Vous pouvez utiliser l'authentification personnalisée avec tous les protocoles de communication pris en AWS IoT Core charge. Pour plus d'informations sur les protocoles pris en charge par AWS IoT Core , consultez [Protocoles de communication des appareils](protocols.md). **Topics** + [Comprendre le flux de travail d'authentification personnalisé](custom-authorizer.md) + [Création et gestion d'autorisateurs personnalisés (CLI)](config-custom-auth.md) + [Authentification personnalisée avec des certificats clients X.509](custom-auth-509cert.md) + [Connexion à l' AWS IoT Core aide de l'authentification personnalisée](custom-auth.md) + [Dépannage de vos mécanismes d'autorisation](custom-auth-troubleshooting.md) # Comprendre le flux de travail d'authentification personnalisé L'authentification personnalisée vous permet de définir comment authentifier et autoriser les clients à l'aide [de ressources de mécanisme d'autorisation](https://docs.aws.amazon.com/iot/latest/apireference/API_AuthorizerDescription.html).  Chaque autorisateur contient une référence à une fonction Lambda gérée par le client, une clé publique facultative pour valider les informations d'identification de l'appareil et des informations de configuration supplémentaires. Le schéma suivant illustre le flux de travail d'autorisation pour l'authentification personnalisée dans AWS IoT Core. ![\[Flux de travail d'autorisation personnalisé pour une authentification personnalisée dans AWS IoT Core.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/custom-authentication.png) ## AWS IoT Core flux de travail d'authentification et d'autorisation personnalisé La liste suivante explique chaque étape du flux de travail d'authentification et d'autorisation personnalisé. 1. Un appareil se connecte au point de terminaison de AWS IoT Core données d'un client à l'aide de l'une des solutions prises en charge[Protocoles de communication des appareils](protocols.md). L'appareil transmet les informations d'identification soit dans les champs d'en-tête de la demande, soit dans les paramètres de requête (pour les WebSockets protocoles HTTP Publish ou MQTT over), soit dans le champ du nom d'utilisateur et du mot de passe du message MQTT CONNECT (pour les protocoles MQTT et MQTT over). WebSockets 1. AWS IoT Core vérifie l'une des deux conditions suivantes : + La demande entrante spécifie un mécanisme d'autorisation. + Un autorisateur par défaut est configuré pour le point de terminaison de AWS IoT Core données recevant la demande. S'il AWS IoT Core trouve un autorisateur de l'une ou l'autre de ces manières, AWS IoT Core déclenche la fonction Lambda associée à l'autorisateur. 1. (Facultatif) Si vous avez activé la signature par jeton, AWS IoT Core valide la signature de la demande en utilisant la clé publique stockée dans l'autorisateur avant de déclencher la fonction Lambda. Si la validation échoue, AWS IoT Core arrête la demande sans invoquer la fonction Lambda.  1. La fonction Lambda reçoit les informations d'identification et les métadonnées de connexion dans la requête et prend une décision d'authentification. 1. La fonction Lambda renvoie les résultats de la décision d'authentification et un document de AWS IoT Core politique qui spécifie les actions autorisées dans la connexion. La fonction Lambda renvoie également des informations qui indiquent à quelle fréquence les informations d'identification contenues dans la demande sont AWS IoT Core revalidées en invoquant la fonction Lambda. 1. AWS IoT Core évalue l'activité de la connexion par rapport à la politique qu'elle a reçue de la fonction Lambda. 1. Une fois que la connexion est établie et que votre Lambda d'autorisation personnalisé est initialement invoqué, l'appel suivant peut être retardé jusqu'à 5 minutes sur les connexions inactives sans aucune opération MQTT. Ensuite, les appels suivants suivront l'intervalle d'actualisation dans votre autorisateur Lambda personnalisé. Cette approche permet d'éviter des appels excessifs susceptibles de dépasser la limite de simultanéité Lambda de votre compte. Compte AWS ## Considérations relatives à la mise à l'échelle Étant donné qu'une fonction Lambda gère l'authentification et l'autorisation de votre mécanisme d'autorisation, la fonction est soumise aux limites de tarification et de service Lambda, telles que le taux d'exécution simultanée. Pour plus d'informations sur la tarification Lambda, consultez [Tarification Lambda](https://aws.amazon.com/lambda/pricing/). Vous pouvez gérer la charge sur votre fonction Lambda en ajustant les paramètres `refreshAfterInSeconds` et `disconnectAfterInSeconds` dans la réponse de votre fonction Lambda. Pour plus d'informations sur le contenu de la réponse de votre fonction Lambda, consultez [Définir votre fonction Lambda](custom-auth-lambda.md). **Note** Si vous laissez la signature activée, vous pouvez empêcher un déclenchement excessif de votre Lambda par des clients non reconnus. Considérez ceci avant de désactiver la connexion à votre mécanisme d'autorisation. **Note** Le délai d'expiration de la fonction Lambda pour le mécanisme d'autorisation personnalisé est de 5 secondes. # Création et gestion d'autorisateurs personnalisés (CLI) AWS IoT Core implémente des schémas d'authentification et d'autorisation personnalisés en utilisant des autorisateurs personnalisés. Un autorisateur personnalisé est une AWS IoT Core ressource qui vous donne la flexibilité de définir et de mettre en œuvre les règles et les politiques en fonction de vos besoins spécifiques. Pour créer un autorisateur personnalisé avec des step-by-step instructions, voir [Tutoriel : Création d'un autorisateur personnalisé](https://docs.aws.amazon.com//iot/latest/developerguide/custom-auth-tutorial.html) pour. AWS IoT Core Chaque mécanisme d'autorisation se compose des éléments suivants : + *Nom* : Une chaîne unique définie par l'utilisateur qui identifie le mécanisme d'autorisation. + *ARN de la fonction Lambda* : Amazon Resource Name (ARN) de la fonction Lambda qui implémente la logique d'autorisation et d'authentification.  + *Nom de clé du jeton* : nom de clé utilisé pour extraire le jeton des en-têtes HTTP, des paramètres de requête ou du nom d'utilisateur MQTT CONNECT afin d'effectuer la validation de la signature. Cette valeur est obligatoire si la signature est activée dans votre mécanisme d'autorisation. + *Indicateur de signature désactivée (facultatif)* : valeur booléenne qui spécifie s'il faut désactiver l'exigence de signature sur les informations d'identification. Ceci est utile pour les scénarios dans lesquels la signature des informations d'identification n'a pas de sens, tels que les schémas d'authentification qui utilisent le nom d'utilisateur et le mot de passe MQTT. La valeur par défaut est `false`, la signature est donc activée par défaut. + *Clé publique de signature de jeton* : clé publique que AWS IoT Core utilise pour valider la signature du jeton. Sa longueur minimale est de 2048 bits. Cette valeur est obligatoire si la signature est activée dans votre mécanisme d'autorisation.  Lambda vous facture le nombre d'exécutions de votre fonction Lambda et le temps nécessaire à l'exécution du code de votre fonction. Pour plus d'informations sur la tarification Lambda, consultez [Tarification Lambda ](https://aws.amazon.com/lambda/pricing/). Pour plus d'informations sur la création de fonctions Lambda, consultez le [Guide du développeur Lambda](https://docs.aws.amazon.com/lambda/latest/dg/). **Note** Si vous laissez la signature activée, vous pouvez empêcher un déclenchement excessif de votre Lambda par des clients non reconnus. Considérez ceci avant de désactiver la connexion à votre mécanisme d'autorisation. **Note** Le délai d'expiration de la fonction Lambda pour le mécanisme d'autorisation personnalisé est de 5 secondes. **Topics** + [Définir votre fonction Lambda](custom-auth-lambda.md) + [Création d'un mécanisme d'autorisation](custom-auth-create-authorizer.md) + [Autorisation d' AWS IoT invoquer votre fonction Lambda](custom-auth-authorize.md) + [Tester vos mécanismes d'autorisation](custom-auth-testing.md) + [Gestion des autorisations personnalisées](custom-auth-manage.md) # Définir votre fonction Lambda Lorsque vous AWS IoT Core invoquez votre autorisateur, il déclenche le Lambda associé à l'autorisateur avec un événement contenant l'objet JSON suivant. L'exemple d'objet JSON contient tous les champs possibles. Tous les champs qui ne sont pas pertinents pour la demande de connexion ne sont pas inclus. ``` {     "token" :"aToken",     "signatureVerified": Boolean, // Indicates whether the device gateway has validated the signature.     "protocols": ["tls", "http", "mqtt"], // Indicates which protocols to expect for the request.     "protocolData": {         "tls" : {             "serverName": "serverName" // The server name indication (SNI) host_name string.         },         "http": {             "headers": {                 "#{name}": "#{value}"             },             "queryString": "?#{name}=#{value}"         },         "mqtt": {             "username": "myUserName",             "password": "myPassword", // A base64-encoded string.             "clientId": "myClientId" // Included in the event only when the device sends the value.         }     },     "connectionMetadata": {         "id": UUID // The connection ID. You can use this for logging.     }, } ``` La fonction Lambda doit utiliser ces informations pour authentifier la connexion entrante et décider quelles actions sont autorisées dans la connexion. La fonction doit envoyer une réponse contenant les valeurs suivantes. + `isAuthenticated`: Une valeur booléenne qui indique si la demande est authentifiée. + `principalId`: Chaîne alphanumérique qui sert d'identifiant pour le jeton envoyé par la demande d'autorisation personnalisée. La valeur doit être une chaîne alphanumérique contenant au moins un et pas plus de 128 caractères et correspondre à ce modèle d'expression régulière (regex) : `([a-zA-Z0-9]){1,128}`. Les caractères spéciaux qui ne sont pas alphanumériques ne sont pas autorisés à être utilisés avec l'entrée`principalId`. AWS IoT Core Reportez-vous à la documentation des autres AWS services si des caractères spéciaux non alphanumériques sont autorisés pour le. `principalId` + `policyDocuments`: liste des documents de AWS IoT Core politique au format JSON Pour plus d'informations sur la création de AWS IoT Core politiques, consultez. [AWS IoT Core politiques](iot-policies.md) Le nombre maximum de documents de stratégie est de 10 documents de stratégie. Chaque document de stratégie peut contenir un maximum de 2048 caractères. + `disconnectAfterInSeconds` : Un entier qui spécifie la durée maximale (en secondes) de la connexion à la passerelle AWS IoT Core . La valeur minimale est de 300 secondes et la valeur maximale de 86 400 secondes. La valeur par défaut est 86 400. **Note** La valeur de `disconnectAfterInSeconds` (renvoyée par la fonction Lambda) est définie lorsque la connexion est établie. Cette valeur ne peut pas être modifiée lors des appels Lambda d'actualisation des politiques ultérieurs. + `refreshAfterInSeconds`: Un entier qui qui spécifie l’intervalle entre les actualisations de stratégie. Lorsque cet intervalle est écoulé, AWS IoT Core appelle la fonction Lambda pour autoriser l'actualisation des stratégies. La valeur minimale est de 300 secondes et la valeur maximale de 86 400 secondes.  L'objet JSON suivant contient un exemple de réponse que votre fonction Lambda peut envoyer. **\$1 "isAuthenticated":true, //A Boolean that determines whether client can connect. "principalId": "xxxxxxxx",  //A string that identifies the connection in logs. "disconnectAfterInSeconds": 86400,  "refreshAfterInSeconds": 300,   "policyDocuments": [       \$1         "Version": "2012-10-17",         "Statement": [            \$1               "Action": "iot:Publish",               "Effect": "Allow",               "Resource": "arn:aws:iot:us-east-1::topic/customauthtesting"             \$1          ]        \$1     ] \$1** La `policyDocument` valeur doit contenir un document AWS IoT Core de politique valide. Pour plus d'informations sur AWS IoT Core les politiques, consultez[AWS IoT Core politiques](iot-policies.md). Dans MQTT sur TLS et MQTT sur WebSockets connexions, met en AWS IoT Core cache cette politique pendant l'intervalle spécifié dans la valeur du champ. `refreshAfterInSeconds` Dans le cas des connexions HTTP, la fonction Lambda est appelée pour chaque demande d'autorisation, sauf si votre appareil utilise des connexions HTTP persistantes (également appelées HTTP keep-alive ou HTTP connection reuse). Vous pouvez choisir d'activer la mise en cache lors de la configuration du mécanisme d'autorisation. Pendant cet intervalle, AWS IoT Core autorise les actions dans une connexion établie par rapport à cette politique mise en cache sans déclencher à nouveau votre fonction Lambda. En cas d'échec lors de l'authentification personnalisée, AWS IoT Core met fin à la connexion. AWS IoT Core met également fin à la connexion si elle est ouverte depuis plus longtemps que la valeur spécifiée dans le `disconnectAfterInSeconds` paramètre. Vous trouverez ci-dessous JavaScript un exemple de fonction Lambda Node.js qui recherche un mot de passe dans le message MQTT Connect avec une valeur `test` égale à et renvoie une politique autorisant la connexion AWS IoT Core avec un client `myClientName` nommé et la publication sur une rubrique contenant le même nom de client. S'il ne trouve pas le mot de passe attendu, il renvoie une stratégie qui refuse ces deux actions. ``` // A simple Lambda function for an authorizer. It demonstrates // how to parse an MQTT password and generate a response. exports.handler = function(event, context, callback) {     var uname = event.protocolData.mqtt.username;     var pwd = event.protocolData.mqtt.password;     var buff = new Buffer(pwd, 'base64');     var passwd = buff.toString('ascii');     switch (passwd) {         case 'test':             callback(null, generateAuthResponse(passwd, 'Allow')); break;         default:             callback(null, generateAuthResponse(passwd, 'Deny'));       } }; // Helper function to generate the authorization response. var generateAuthResponse = function(token, effect) { var authResponse = {}; authResponse.isAuthenticated = true; authResponse.principalId = 'TEST123'; var policyDocument = {}; policyDocument.Version = '2012-10-17'; policyDocument.Statement = []; var publishStatement = {}; var connectStatement = {}; connectStatement.Action = ["iot:Connect"]; connectStatement.Effect = effect; connectStatement.Resource = ["arn:aws:iot:us-east-1:123456789012:client/myClientName"]; publishStatement.Action = ["iot:Publish"]; publishStatement.Effect = effect; publishStatement.Resource = ["arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName"]; policyDocument.Statement[0] = connectStatement; policyDocument.Statement[1] = publishStatement; authResponse.policyDocuments = [policyDocument]; authResponse.disconnectAfterInSeconds = 3600; authResponse.refreshAfterInSeconds = 300; return authResponse; } ``` La fonction Lambda précédente renvoie le JSON suivant lorsqu'elle reçoit le mot de passe `test` attendu dans le message MQTT Connect. Les valeurs des propriétés `password` et `principalId` seront les valeurs du message MQTT Connect. ``` { "password": "password", "isAuthenticated": true, "principalId": "principalId", "policyDocuments": [ { "Version": "2012-10-17", "Statement": [ { "Action": "iot:Connect", "Effect": "Allow", "Resource": "*" }, { "Action": "iot:Publish", "Effect": "Allow", "Resource": "arn:aws:iot:region:accountId:topic/telemetry/${iot:ClientId}" }, { "Action": "iot:Subscribe", "Effect": "Allow", "Resource": "arn:aws:iot:region:accountId:topicfilter/telemetry/${iot:ClientId}" }, { "Action": "iot:Receive", "Effect": "Allow", "Resource": "arn:aws:iot:region:accountId:topic/telemetry/${iot:ClientId}" } ] } ], "disconnectAfterInSeconds": 3600, "refreshAfterInSeconds": 300 } ``` # Création d'un mécanisme d'autorisation Vous pouvez créer un autorisateur à l'aide de l'[CreateAuthorizerAPI](https://docs.aws.amazon.com/iot/latest/apireference/API_CreateAuthorizer.html). L'exemple suivant décrit la commande. ``` aws iot create-authorizer --authorizer-name MyAuthorizer --authorizer-function-arn arn:aws:lambda:us-west-2::function:MyAuthorizerFunction  //The ARN of the Lambda function. [--token-key-name MyAuthorizerToken //The key used to extract the token from headers. [--token-signing-public-keys FirstKey= "-----BEGIN PUBLIC KEY-----   [...insert your public key here...]   -----END PUBLIC KEY-----" [--status ACTIVE] [--tags ] [--signing-disabled | --no-signing-disabled] ``` Vous pouvez utiliser le paramètre `signing-disabled` pour désactiver la validation de signature pour chaque invocation de votre mécanisme d'autorisation. Nous vous recommandons fortement de ne pas désactiver la signature, sauf si vous y êtes obligé. La validation de signature vous protège contre les appels excessifs de votre fonction Lambda à partir d'appareils inconnus. Vous ne pouvez pas mettre à jour l'état `signing-disabled` d'un organisme d'autorisation après l'avoir créé. Pour modifier ce comportement, vous devez créer un autre mécanisme d'autorisation personnalisé avec une valeur différente pour le paramètre `signing-disabled`. Les valeurs des paramètres `tokenKeyName` et `tokenSigningPublicKeys` sont facultatives si vous avez désactivé la signature. Ce sont des valeurs obligatoires si la signature est activée. Après avoir créé votre fonction Lambda et l'autorisateur personnalisé, vous devez explicitement accorder au AWS IoT Core service l'autorisation d'appeler la fonction en votre nom. Vous pouvez le faire à l'aide de la commande suivante. **Note** Le point de terminaison IoT par défaut peut ne pas prendre en charge l'utilisation d'autorisateurs personnalisés dotés de fonctions Lambda. Vous pouvez plutôt utiliser des configurations de domaine pour définir un nouveau point de terminaison, puis spécifier ce point de terminaison pour l'autorisateur personnalisé. ``` aws lambda add-permission --function-name --principal iot.amazonaws.com --source-arn --statement-id Id-123 --action "lambda:InvokeFunction" ``` # Autorisation d' AWS IoT invoquer votre fonction Lambda Dans cette section, vous allez autoriser la ressource d'autorisation personnalisée que vous venez de créer pour exécuter la fonction Lambda. Pour accorder l'autorisation, vous pouvez utiliser la commande CLI [add-permission](https://docs.aws.amazon.com//cli/latest/reference/lambda/add-permission.html). **Accordez l'autorisation à votre fonction Lambda à l'aide du AWS CLI** 1. Après avoir inséré vos valeurs, entrez la commande suivante. Notez que la valeur `statement-id` doit être unique. Remplacez `Id-1234` par la valeur exacte que vous avez, sinon vous risquez de recevoir une `ResourceConflictException` erreur. ``` aws lambda add-permission \ --function-name "custom-auth-function" \ --principal "iot.amazonaws.com" \ --action "lambda:InvokeFunction" \ --statement-id "Id-1234" \ --source-arn authorizerArn ``` 1. Si la commande aboutit, elle renvoie une instruction d'autorisation, comme dans cet exemple. Vous pouvez passer à la section suivante pour tester le mécanisme d’autorisation personnalisée. ``` { "Statement": "{\"Sid\":\"Id-1234\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"iot.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:Region:57EXAMPLE833:function:custom-auth-function\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:lambda:Region:57EXAMPLE833:function:custom-auth-function\"}}}" } ``` Si la commande échoue, elle renvoie une erreur, comme dans cet exemple. Vous devez vérifier et corriger l'erreur avant de continuer. ``` An error occurred (AccessDeniedException) when calling the AddPermission operation: User: arn:aws:iam::57EXAMPLE833:user/EXAMPLE-1 is not authorized to perform: lambda:AddPer mission on resource: arn:aws:lambda:Region:57EXAMPLE833:function:custom-auth-function ``` # Tester vos mécanismes d'autorisation Vous pouvez utiliser l'[TestInvokeAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_TestInvokeAuthorizer.html)API pour tester les valeurs d'invocation et de retour de votre autorisateur. Cette API vous permet de spécifier les métadonnées du protocole et de tester la validation de signature dans votre autorisateur. Les onglets suivants montrent comment utiliser le AWS CLI pour tester votre autorisateur. ------ #### [ Unix-like ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER \ --token TOKEN_VALUE --token-signature TOKEN_SIGNATURE ``` ------ #### [ Windows CMD ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER ^ --token TOKEN_VALUE --token-signature TOKEN_SIGNATURE ``` ------ #### [ Windows PowerShell ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER ` --token TOKEN_VALUE --token-signature TOKEN_SIGNATURE ``` ------ La valeur du paramètre `token-signature` est le jeton signé. Pour savoir comment obtenir cette valeur, consultez [Signer le jeton](custom-auth.md#custom-auth-token-signature). Si votre mécanisme d'autorisation prend un nom d'utilisateur et un mot de passe, vous pouvez transmettre ces informations en utilisant le paramètre `--mqtt-context`. Les onglets suivants montrent comment utiliser l'API `TestInvokeAuthorizer` pour envoyer un objet JSON contenant un nom d'utilisateur, un mot de passe et un nom de client à votre mécanisme d'autorisation personnalisé. ------ #### [ Unix-like ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER \ --mqtt-context '{"username": "USER_NAME", "password": "dGVzdA==", "clientId":"CLIENT_NAME"}' ``` ------ #### [ Windows CMD ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER ^ --mqtt-context '{"username": "USER_NAME", "password": "dGVzdA==", "clientId":"CLIENT_NAME"}' ``` ------ #### [ Windows PowerShell ] ``` aws iot test-invoke-authorizer --authorizer-name NAME_OF_AUTHORIZER ` --mqtt-context '{"username": "USER_NAME", "password": "dGVzdA==", "clientId":"CLIENT_NAME"}' ``` ------ Le mot de passe doit être codé en base64. L'exemple suivant montre comment coder un mot de passe dans un environnement de type Unix. ``` echo -n PASSWORD | base64 ``` # Gestion des autorisations personnalisées Vous pouvez gérer vos autorisateurs à l'aide des méthodes suivantes APIs. + [ListAuthorizers](https://docs.aws.amazon.com/iot/latest/apireference/API_ListAuthorizers.html): Afficher tous les autorisateurs de votre compte. + [DescribeAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeAuthorizer.html): affiche les propriétés de l'autorisateur spécifié. Ces valeurs incluent la date de création, la date de la dernière modification et d'autres attributs. + [SetDefaultAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_SetDefaultAuthorizer.html): Spécifie l'autorisateur par défaut pour vos points de terminaison AWS IoT Core de données. AWS IoT Core utilise cet autorisateur si un appareil ne transmet pas les AWS IoT Core informations d'identification et ne spécifie pas d'autorisateur. Pour plus d'informations sur l'utilisation des AWS IoT Core informations d'identification, consultez[Authentification client](client-authentication.md). + [UpdateAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateAuthorizer.html): modifie le statut, le nom de la clé du jeton ou les clés publiques de l'autorisateur spécifié. + [DeleteAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_DeleteAuthorizer.html): Supprime l'autorisateur spécifié. **Note** Vous ne pouvez pas mettre à jour les exigences de signature d'un mécanisme d'autorisation. Cela signifie que vous ne pouvez pas désactiver la connexion si un mécanisme d'autorisation existant l'exige. Vous ne pouvez pas non plus exiger la connexion d’un mécanisme d’autorisation existant qui ne l’exige pas. # Authentification personnalisée avec des certificats clients X.509 Lorsque vous connectez des appareils à AWS IoT Core, plusieurs [types d'authentification](protocols.md#connection-protocol-auth-mode) sont disponibles. Vous pouvez utiliser des [certificats client X.509](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html) qui peuvent être utilisés pour authentifier les connexions des clients et des appareils, ou définir des [autorisateurs personnalisés](https://docs.aws.amazon.com//iot/latest/developerguide/custom-authentication.html) pour gérer votre propre logique d'authentification et d'autorisation des clients. Cette rubrique explique comment utiliser l'authentification personnalisée avec les certificats client X.509. L'utilisation de l'authentification personnalisée avec des certificats X.509 peut être utile si vous avez déjà authentifié vos appareils à l'aide de certificats X.509 et que vous souhaitez effectuer une validation supplémentaire et une autorisation personnalisée. Par exemple, si vous stockez les données de vos appareils, telles que leurs numéros de série, dans le certificat client X.509, après avoir AWS IoT Core authentifié le certificat client X.509, vous pouvez utiliser un autorisateur personnalisé pour identifier des appareils spécifiques en fonction des informations stockées dans le champ du certificat. CommonName L'utilisation de l'authentification personnalisée avec des certificats X.509 peut améliorer la gestion de la sécurité de vos appareils lors de la connexion des appareils AWS IoT Core et offre plus de flexibilité pour gérer la logique d'authentification et d'autorisation. AWS IoT Core [prend en charge l'authentification personnalisée avec des certificats X.509 utilisant le certificat X.509 et le type d'authentification d'autorisation personnalisé, qui fonctionne à la fois avec le protocole [MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html) et le protocole HTTPS.](https://docs.aws.amazon.com//iot/latest/developerguide/http.html) Pour plus d'informations sur les types d'authentification et les protocoles d'application pris en charge par les terminaux des AWS IoT Core appareils, consultez la section [Protocoles de communication des appareils](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html). **Note** L'authentification personnalisée à l'aide de certificats clients X.509 n'est pas prise en charge dans les AWS GovCloud (US) régions. **Important** Vous devez utiliser un point de terminaison créé à l'aide [de configurations de domaine](iot-custom-endpoints-configurable.md). En outre, les clients doivent fournir l'extension [SNI (Server Name Indication)](https://www.rfc-editor.org/rfc/rfc3546#section-3.1) lorsqu'ils se connectent à AWS IoT Core. **Topics** + [Étape 1 : enregistrez vos certificats clients X.509 auprès de AWS IoT Core](#custom-auth-509cert-client) + [Étape 2 : création d’une fonction Lambda](#custom-auth-509cert-lambda) + [Étape 3 : créer un autorisateur personnalisé](#custom-auth-509cert-authorizer) + [Étape 4 : définir le type d'authentification et le protocole d'application dans une configuration de domaine](#custom-auth-509cert-domainconfig) ## Étape 1 : enregistrez vos certificats clients X.509 auprès de AWS IoT Core Si ce n'est pas déjà fait, enregistrez et activez vos [certificats clients X.509](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html) avec AWS IoT Core. Sinon, passez à l’étape suivante. Pour enregistrer et activer vos certificats clients auprès de AWS IoT Core, procédez comme suit : 1. Si vous [créez des certificats clients directement avec AWS IoT](https://docs.aws.amazon.com//iot/latest/developerguide/device-certs-create.html). Ces certificats clients seront automatiquement enregistrés auprès de AWS IoT Core. 1. Si vous [créez vos propres certificats clients](https://docs.aws.amazon.com//iot/latest/developerguide/device-certs-your-own.html), suivez [ces instructions pour les enregistrer auprès](https://docs.aws.amazon.com//iot/latest/developerguide/register-device-cert.html) de AWS IoT Core. 1. Pour activer vos certificats clients, suivez [ces instructions](https://docs.aws.amazon.com//iot/latest/developerguide/activate-or-deactivate-device-cert.html). ## Étape 2 : création d’une fonction Lambda AWS IoT Core utilise des autorisateurs personnalisés pour implémenter des schémas d'authentification et d'autorisation personnalisés. Un autorisateur personnalisé est associé à une fonction Lambda qui détermine si un appareil est authentifié et quelles opérations le périphérique est autorisé à effectuer. Lorsqu'un appareil se connecte à AWS IoT Core, AWS IoT Core récupère les détails de l'autorisateur, y compris le nom de l'autorisateur et la fonction Lambda associée, et invoque la fonction Lambda. La fonction Lambda reçoit un événement contenant un objet JSON contenant les données du certificat client X.509 du périphérique. Votre fonction Lambda utilise cet objet JSON d'événement pour évaluer la demande d'authentification, décider des actions à entreprendre et renvoyer une réponse. ### Exemple d'événement lié à une fonction Lambda L'exemple d'objet JSON suivant contient tous les champs possibles qui peuvent être inclus. L'objet JSON proprement dit ne contiendra que les champs relatifs à la demande de connexion spécifique. ``` { "token": "aToken", "signatureVerified": true, "protocols": [ "tls", "mqtt" ], "protocolData": { "tls": { "serverName": "serverName", "x509CertificatePem": "x509CertificatePem", "principalId": "principalId" }, "mqtt": { "clientId": "myClientId", "username": "myUserName", "password": "myPassword" } }, "connectionMetadata": { "id": "UUID" } } ``` `signatureVerified` Valeur booléenne qui indique si la signature du jeton configurée dans l'autorisateur est vérifiée ou non avant d'appeler la fonction Lambda de l'autorisateur. Si l'autorisateur est configuré pour désactiver la signature par jeton, ce champ sera faux. `protocols` Tableau contenant les protocoles attendus pour la demande. `protocolData` Objet contenant des informations sur les protocoles utilisés dans la connexion. Il fournit des informations spécifiques au protocole qui peuvent être utiles pour l'authentification, l'autorisation, etc. `tls`- Cet objet contient des informations relatives au protocole TLS (Transport Layer Security). + `serverName`- La chaîne de [nom d'hôte SNI (Server Name Indication)](https://www.rfc-editor.org/rfc/rfc3546#section-3.1). AWS IoT Core exige que les appareils envoient l'[extension SNI](https://www.rfc-editor.org/rfc/rfc3546#section-3.1) au protocole TLS (Transport Layer Security) et fournissent l'adresse complète du point de terminaison sur le `host_name` terrain. + `x509CertificatePem`- Le certificat X.509 au format PEM, qui est utilisé pour l'authentification du client dans la connexion TLS. + `principalId`- L'identifiant principal associé au client dans la connexion TLS. `mqtt`- Cet objet contient des informations relatives au protocole MQTT. + `clientId`- Une chaîne ne doit être incluse que dans le cas où l'appareil envoie cette valeur. + `username`- Le nom d'utilisateur fourni dans le paquet MQTT Connect. + `password`- Le mot de passe fourni dans le paquet MQTT Connect. `connectionMetadata` Métadonnées de la connexion. `id`- L'identifiant de connexion, que vous pouvez utiliser pour la journalisation et le dépannage. **Note** Dans ce cas, il s'agit d'un objet JSON `x509CertificatePem` et `principalId` deux nouveaux champs figurent dans la demande. La valeur de `principalId` est identique à la valeur de`certificateId`. Pour plus d'informations, consultez la section [Certificat](https://docs.aws.amazon.com//iot/latest/apireference/API_Certificate.html). ### Exemple de réponse de la fonction Lambda La fonction Lambda doit utiliser les informations de l'objet JSON d'événement pour authentifier la connexion entrante et décider quelles actions sont autorisées dans la connexion. L'objet JSON suivant contient un exemple de réponse que votre fonction Lambda peut envoyer. ``` { "isAuthenticated": true, "principalId": "xxxxxxxx", "disconnectAfterInSeconds": 86400, "refreshAfterInSeconds": 300, "policyDocuments": [ { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Publish", "Resource": "arn:aws:iot:us-east-1:123456789012:topic/customauthtesting" } ] } ] } ``` Dans cet exemple, cette fonction doit envoyer une réponse contenant les valeurs suivantes. `isAuthenticated` Valeur booléenne qui indique si la demande est authentifiée. `principalId` Chaîne alphanumérique qui sert d'identifiant pour le jeton envoyé par la demande d'autorisation personnalisée. La valeur doit être une chaîne alphanumérique comportant au moins un caractère, mais pas plus de 128. Il identifie la connexion dans les journaux. La valeur de `principalId` doit être identique à la valeur de l'objet JSON `principalId` de l'événement (c'est-à-dire le certificateID du certificat X.509). `policyDocuments` Liste des documents de politique au format JSON AWS IoT Core . La valeur est facultative et prend en charge les [variables de politique d'objet et les variables](https://docs.aws.amazon.com//iot/latest/developerguide/thing-policy-variables.html) [de politique de certificat](https://docs.aws.amazon.com//iot/latest/developerguide/cert-policy-variables.html). Le nombre maximum de documents de politique est de 10. Chaque document de stratégie peut contenir un maximum de 2048 caractères. Si plusieurs politiques sont associées à votre certificat client et à la fonction Lambda, l'autorisation est un ensemble de toutes les politiques. Pour plus d'informations sur la création de AWS IoT Core politiques, consultez la section [Politiques](https://docs.aws.amazon.com//iot/latest/developerguide/iot-policies.html). `disconnectAfterInSeconds` Nombre entier qui indique la durée maximale (en secondes) de la connexion à la AWS IoT Core passerelle. La valeur minimale est de 300 secondes et la valeur maximale de 86 400 secondes. `disconnectAfterInSeconds`est valable pour la durée de vie d'une connexion et n'est pas actualisé lors de mises à jour consécutives des politiques. `refreshAfterInSeconds` Nombre entier qui indique l'intervalle entre les actualisations des politiques. Lorsque cet intervalle est dépassé, AWS IoT Core invoque la fonction Lambda pour permettre l'actualisation des politiques. La valeur minimale est de 300 secondes et la valeur maximale de 86 400 secondes. ### Exemple de fonction Lambda Voici un exemple de fonction Lambda de Node.js. La fonction examine le certificat X.509 du client et extrait les informations pertinentes telles que le numéro de série, l'empreinte digitale et le nom du sujet. Si les informations extraites correspondent aux valeurs attendues, le client est autorisé à se connecter. Ce mécanisme garantit que seuls les clients autorisés possédant des certificats valides peuvent établir une connexion. ``` const crypto = require('crypto'); exports.handler = async (event) => { // Extract the certificate PEM from the event const certPem = event.protocolData.tls.x509CertificatePem; // Parse the certificate using Node's crypto module const cert = new crypto.X509Certificate(certPem); var effect = "Deny"; // Allow permissions only for a particular certificate serial, fingerprint, and subject if (cert.serialNumber === "7F8D2E4B9C1A5036DE8F7C4B2A91E5D80463BC9A1257" // This is a random serial && cert.fingerprint === "F2:9A:C4:1D:B5:E7:08:3F:6B:D0:4E:92:A7:C1:5B:8D:16:0F:E3:7A" // This is a random fingerprint && cert.subject === "allow.example.com") { effect = "Allow"; } return generateAuthResponse(event.protocolData.tls.principalId, effect); }; // Helper function to generate the authorization response. function generateAuthResponse(principalId, effect) { const authResponse = { isAuthenticated: true, principalId, disconnectAfterInSeconds: 3600, refreshAfterInSeconds: 300, policyDocuments: [ { Version: "2012-10-17", Statement: [ { Action: ["iot:Connect"], Effect: effect, Resource: [ "arn:aws:iot:us-east-1:123456789012:client/myClientName" ] }, { Action: ["iot:Publish"], Effect: effect, Resource: [ "arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName" ] }, { Action: ["iot:Subscribe"], Effect: effect, Resource: [ "arn:aws:iot:us-east-1:123456789012:topicfilter/telemetry/myClientName" ] }, { Action: ["iot:Receive"], Effect: effect, Resource: [ "arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName" ] } ] } ] }; return authResponse; } ``` La fonction Lambda précédente renvoie le code JSON suivant lorsqu'elle reçoit un certificat avec le numéro de série, l'empreinte digitale et le sujet attendus. La valeur de `x509CertificatePem` sera le certificat client fourni lors de la poignée de contact TLS. Pour plus d'informations, consultez la section [Définition de votre fonction Lambda](https://docs.aws.amazon.com//iot/latest/developerguide/config-custom-auth.html#custom-auth-lambda). ``` { "isAuthenticated": true, "principalId": "principalId in the event JSON object", "policyDocuments": [ { "Version": "2012-10-17", "Statement": [ { "Action": "iot:Connect", "Effect": "Allow", "Resource": "arn:aws:iot:us-east-1:123456789012:client/myClientName" }, { "Action": "iot:Publish", "Effect": "Allow", "Resource": "arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName" }, { "Action": "iot:Subscribe", "Effect": "Allow", "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/telemetry/myClientName" }, { "Action": "iot:Receive", "Effect": "Allow", "Resource": "arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName" } ] } ], "disconnectAfterInSeconds": 3600, "refreshAfterInSeconds": 300 } ``` ## Étape 3 : créer un autorisateur personnalisé Après [avoir défini la fonction Lambda](#custom-auth-509cert-lambda), créez un autorisateur personnalisé pour gérer votre propre logique d'authentification et d'autorisation du client. Vous pouvez suivre les instructions détaillées de l'[étape 3 : créer une ressource d'autorisation client et son autorisation](https://docs.aws.amazon.com//iot/latest/developerguide/custom-auth-tutorial.html#custom-auth-tutorial-authorizer). Pour plus d'informations, consultez la section [Création d'un autorisateur.](https://docs.aws.amazon.com//iot/latest/developerguide/config-custom-auth.html) Lors de la création de l'autorisateur personnalisé, vous devez AWS IoT autoriser l'appel de la fonction Lambda après sa création. Pour obtenir des instructions détaillées, consultez [Autoriser l'appel AWS IoT de votre fonction Lambda](custom-auth-authorize.md). ## Étape 4 : définir le type d'authentification et le protocole d'application dans une configuration de domaine Pour authentifier les appareils à l'aide d'une authentification personnalisée avec des certificats clients X.509, vous devez définir le type d'authentification et le protocole d'application dans une configuration de domaine, et vous devez envoyer l'extension SNI. La valeur de `authenticationType` doit être`CUSTOM_AUTH_X509`, et la valeur de `applicationProtocol` peut être `SECURE_MQTT` ou`HTTPS`. ### Définissez le type d'authentification et le protocole d'application dans la configuration du domaine (CLI) Si vous n'avez pas de configuration de domaine, utilisez la [https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/create-domain-configuration.html)commande pour en créer une. La valeur de `authenticationType` doit être`CUSTOM_AUTH_X509`, et la valeur de `applicationProtocol` peut être `SECURE_MQTT` ou`HTTPS`. ``` aws iot create-domain-configuration \ --domain-configuration-name domainConfigurationName \ --authentication-type CUSTOM_AUTH_X509 \ --application-protocol SECURE_MQTT \ --authorizer-config '{ "defaultAuthorizerName": my-custom-authorizer }' ``` Si vous avez déjà une configuration de domaine, utilisez la [https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html](https://docs.aws.amazon.com//cli/latest/reference/iot/update-domain-configuration.html)commande update `authenticationType` et `applicationProtocol` si nécessaire. Notez que vous ne pouvez pas modifier le type ou le protocole d'authentification sur le point de terminaison par défaut (`iot:Data-ATS`). ``` aws iot update-domain-configuration \ --domain-configuration-name domainConfigurationName \ --authentication-type CUSTOM_AUTH_X509 \ --application-protocol SECURE_MQTT \ --authorizer-config '{ "defaultAuthorizerName": my-custom-authorizer }' ``` `domain-configuration-name` Nom de la configuration de domaine. `authentication-type` Type d'authentification de la configuration du domaine. Pour plus d'informations, consultez la section [Choix d'un type d'authentification](protocols.md#connection-protocol-auth-mode). `application-protocol` Protocole d'application avec lequel les appareils communiquent AWS IoT Core. Pour plus d'informations, consultez la section [Choix d'un protocole d'application](protocols.md#protocol-selection). `--authorizer-config` Objet qui spécifie la configuration de l'autorisateur dans une configuration de domaine. `defaultAuthorizerName` Nom de l'autorisateur pour une configuration de domaine. Pour plus d'informations, consultez [CreateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_CreateDomainConfiguration.html)et consultez le [UpdateDomainConfiguration](https://docs.aws.amazon.com//iot/latest/apireference/API_UpdateDomainConfiguration.html)Guide de *référence des AWS IoT API*. Pour plus d'informations sur la configuration des domaines, consultez la section [Configurations des domaines](https://docs.aws.amazon.com//iot/latest/developerguide/iot-custom-endpoints-configurable.html). # Connexion à l' AWS IoT Core aide de l'authentification personnalisée Les appareils peuvent se connecter à AWS IoT Core l'aide d'une authentification personnalisée avec n'importe quel protocole prenant AWS IoT Core en charge la messagerie des appareils. Pour plus d'informations sur les protocoles de communication pris en charge, consultez [Protocoles de communication des appareils](protocols.md).  Les données de connexion que vous transmettez à votre fonction Lambda d'autorisation dépendent du protocole que vous utilisez. Pour plus d'informations sur la création de votre fonction Lambda d'autorisation, consultez [Définir votre fonction Lambda](custom-auth-lambda.md). Les sections suivantes expliquent comment se connecter pour s'authentifier à l'aide de chaque protocole pris en charge. ## HTTPS Les appareils qui envoient des données à AWS IoT Core l'aide de l'[API HTTP Publish](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_Publish.html) peuvent transmettre des informations d'identification par le biais d'en-têtes de requête ou de paramètres de requête dans leurs requêtes HTTP POST. Les appareils peuvent spécifier un mécanisme d'autorisation à invoquer à l'aide du paramètre d'en-tête `x-amz-customauthorizer-name` ou de requête. Si la signature de jetons est activée dans votre mécanisme d'autorisation, vous devez transmettre le `token-key-name` et `x-amz-customauthorizer-signature` dans les en-têtes ou paramètres de requête. Notez que la `token-signature` valeur doit être codée en URL lorsque vous l'utilisez JavaScript depuis le navigateur. **Note** Le mécanisme d'autorisation client pour le protocole HTTPS prend uniquement en charge les opérations de publication. Pour plus d'informations sur le protocole HTTPS, consultez [Protocoles de communication des appareils](protocols.md). Les exemples de requêtes suivants montrent comment transmettre ces paramètres dans les en-têtes et paramètres de requête. ``` //Passing credentials via headers POST /topics/topic?qos=qos HTTP/1.1 Host: your-endpoint  x-amz-customauthorizer-signature: token-signature token-key-name: token-value  x-amz-customauthorizer-name: authorizer-name //Passing credentials via query parameters POST /topics/topic?qos=qos&x-amz-customauthorizer-signature=token-signature&token-key-name=token-value HTTP/1.1 ``` ## MQTT Les appareils qui se connectent à AWS IoT Core l'aide d'une connexion MQTT peuvent transmettre des informations d'identification via les `password` champs `username` et des messages MQTT. La valeur `username` peut éventuellement contenir une chaîne de requête qui transmet des valeurs supplémentaires (y compris un jeton, une signature et un nom du mécanisme d'autorisation) à votre mécanisme d'autorisation. Vous pouvez utiliser cette chaîne de requête si vous souhaitez utiliser un schéma d'authentification basé sur un jeton au lieu des valeurs `password` et `username`.  **Note** Les données du champ du mot de passe sont codées en base64 par. AWS IoT Core Votre fonction Lambda doit le décoder. L'exemple suivant contient une chaîne `username` contenant des paramètres supplémentaires spécifiant un jeton et une signature.  ``` username?x-amz-customauthorizer-name=authorizer-name&x-amz-customauthorizer-signature=token-signature&token-key-name=token-value ``` Pour appeler un autorisateur, les appareils qui se connectent à l'aide AWS IoT Core de MQTT et d'une authentification personnalisée doivent se connecter sur le port 443. Ils doivent également transmettre l'extension TLS ALPN (Application Layer Protocol Negotiation) avec une valeur égale à `mqtt` et l'extension SNI (Server Name Indication) avec le nom d'hôte de leur AWS IoT Core point de terminaison de données. Pour éviter des erreurs potentielles, la valeur de `x-amz-customauthorizer-signature` doit être codée en URL. Nous recommandons fortement que les valeurs de `x-amz-customauthorizer-name` et `token-key-name` soient codées en URL. Pour plus d'informations sur ces valeurs, consultez [Protocoles de communication des appareils](protocols.md). Le [AWS IoT Appareil SDKs, appareil mobile SDKs et client AWS IoT d'appareil](iot-sdks.md) V2 peut configurer ces deux extensions.  ## MQTT terminé WebSockets Les appareils qui se connectent à AWS IoT Core l'aide de MQTT over WebSockets peuvent transmettre des informations d'identification de l'une des deux manières suivantes. + Via les en-têtes de requête ou les paramètres de requête contenus dans la demande HTTP UPGRADE pour établir la WebSockets connexion. + Via les champs `username` et `password` dans le message MQTT CONNECT. Si vous transmettez les informations d'identification via le message de connexion MQTT, les extensions ALPN et SNI TLS sont requises. Pour plus d'informations sur ces extensions, consultez [MQTT](#custom-auth-mqtt). L'exemple suivant montre comment transmettre les informations d'identification via la demande de mise à niveau HTTP. ``` GET /mqtt HTTP/1.1 Host: your-endpoint Upgrade: WebSocket Connection: Upgrade x-amz-customauthorizer-signature: token-signature token-key-name: token-value  sec-WebSocket-Key: any random base64 value sec-websocket-protocol: mqtt sec-WebSocket-Version: websocket version ``` ## Signer le jeton Vous devez signer le jeton avec la clé privée de la paire de clés publique-privée que vous avez utilisée lors de l'appel `create-authorizer`. Les exemples suivants montrent comment créer la signature du jeton à l'aide d'une commande de type Unix et. JavaScript Ils utilisent l'algorithme de hachage SHA-256 pour coder la signature. ------ #### [ Command line ] ``` echo -n TOKEN_VALUE | openssl dgst -sha256 -sign PEM encoded RSA private key | openssl base64 ``` ------ #### [ JavaScript ] ``` const crypto = require('crypto') const key = "PEM encoded RSA private key" const k = crypto.createPrivateKey(key) let sign = crypto.createSign('SHA256') sign.write(t) sign.end() const s = sign.sign(k, 'base64') ``` ------ # Dépannage de vos mécanismes d'autorisation Cette rubrique passe en revue les problèmes courants des flux de travail d'authentification personnalisés et les étapes pour les résoudre. Pour résoudre les problèmes le plus efficacement possible, activez les CloudWatch journaux pour DEBUG AWS IoT Core et définissez le niveau de journalisation sur **DEBUG**. Vous pouvez activer CloudWatch les journaux dans la AWS IoT Core console ([https://console.aws.amazon.com/iot/](https://console.aws.amazon.com/iot/)). Pour plus d'informations sur l'activation et la configuration des journaux pour AWS IoT Core, consultez [Configuration de la AWS IoT journalisation](configure-logging.md). **Note** Si vous laissez le niveau de journalisation au niveau **DEBUG** pendant de longues périodes, vous CloudWatch risquez de stocker de grandes quantités de données de journalisation. Cela peut augmenter vos CloudWatch frais. Envisagez d'utiliser la journalisation basée sur les ressources pour augmenter la verbosité uniquement pour les appareils d'un groupe d'objets particulier. Pour plus d'informations sur la journalisation basée sur les ressources, consultez [Configuration de la AWS IoT journalisation](configure-logging.md). De plus, une fois le dépannage terminé, réduisez le niveau du journal à un niveau moins détaillé. Avant de commencer le dépannage, consultez [Comprendre le flux de travail d'authentification personnalisé](custom-authorizer.md) pour un aperçu général du processus d'authentification personnalisé. Cela vous aide à comprendre où chercher la source d’un problème. Cette rubrique aborde les deux domaines suivants que vous devez étudier. + Problèmes liés à la fonction Lambda de votre mécanisme d'autorisation. + Problèmes liés à votre appareil. ## Recherchez les problèmes dans la fonction Lambda de votre mécanisme d'autorisation Effectuez les étapes suivantes pour vous assurer que les tentatives de connexion de vos appareils invoquent votre fonction Lambda. 1. Vérifiez quelle fonction Lambda est associée à votre mécanisme d'autorisation. Vous pouvez le faire en appelant l'[DescribeAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeAuthorizer.html)API ou en cliquant sur l'autorisateur souhaité dans la section **Secure** de la AWS IoT Core console. 1. Vérifiez les métriques d’invocation pour la fonction Lambda. Effectuez les étapes suivantes pour ce faire. 1. Ouvrez la AWS Lambda console ([https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)) et sélectionnez la fonction associée à votre autorisateur. 1. Choisissez l’onglet **Surveiller** et affichez les métriques pour la période pertinente à votre problème. 1. Si vous ne voyez aucune invocation, vérifiez qu' AWS IoT Core elle est autorisée à appeler votre fonction Lambda. Si vous voyez des invocations, passez à l’étape suivante. Effectuez les étapes suivantes pour vérifier que votre fonction Lambda dispose des autorisations requises. 1. Choisissez l'onglet **Autorisations** correspondant à votre fonction dans la AWS Lambda console. 1. Recherchez la section **Stratégie basée sur les ressources** au bas de la page. Si votre fonction Lambda dispose des autorisations requises, la stratégie ressemble à l'exemple suivant. **** ``` { "Version":"2012-10-17", "Id": "default", "Statement": [ { "Sid": "Id123", "Effect": "Allow", "Principal": { "Service": "iot.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:111111111111:function:FunctionName", "Condition": { "ArnLike": { "AWS:SourceArn": "arn:aws:iot:us-east-1:111111111111:authorizer/AuthorizerName" }, "StringEquals": { "AWS:SourceAccount": "111111111111" } } } ] } ``` 1. Cette politique accorde l'`InvokeFunction`autorisation d'accéder à votre fonction au AWS IoT Core directeur. Si vous ne le voyez pas, vous devrez l'ajouter à l'aide de l'[AddPermission](https://docs.aws.amazon.com/lambda/latest/dg/API_AddPermission.html)API. L'exemple suivant vous montre comment procéder en utilisant le AWS CLI. ``` aws lambda add-permission --function-name FunctionName --principal iot.amazonaws.com --source-arn AuthorizerARn --statement-id Id-123 --action "lambda:InvokeFunction" ``` 1. Si vous voyez des invocations, vérifiez qu’il n’y a pas d’erreurs. Une erreur peut indiquer que la fonction Lambda ne gère pas correctement l'événement de connexion qui AWS IoT Core lui est envoyé. Pour plus d'informations sur la gestion de l'événement dans votre fonction Lambda, consultez [Définir votre fonction Lambda](custom-auth-lambda.md). Vous pouvez utiliser la fonction de test de la AWS Lambda console ([https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)) pour coder en dur les valeurs de test de la fonction afin de vous assurer que celle-ci gère correctement les événements. 1. Si vous voyez des invocations sans erreur, mais que vos appareils ne parviennent pas à se connecter (ou à publier, s'abonner et recevoir des messages), le problème peut être que la stratégie renvoyée par votre fonction Lambda n'accorde pas d'autorisations pour les actions que vos appareils effectuent. Effectuez les étapes suivantes pour déterminer si quelque chose ne va pas avec la stratégie renvoyée par la fonction. 1. Utilisez une requête Amazon CloudWatch Logs Insights pour analyser les journaux sur une courte période afin de détecter les défaillances. L'exemple de requête suivant trie les événements par horodatage et recherche les échecs. ``` display clientId, eventType, status, @timestamp | sort @timestamp desc | filter status = "Failure" ``` 1. Mettez à jour votre fonction Lambda pour enregistrer les données auxquelles elle renvoie AWS IoT Core et l'événement qui déclenche la fonction. Vous pouvez utiliser ces journaux pour inspecter la stratégie créée par la fonction. 1. Si vous voyez des invocations sans erreur, mais que vos appareils ne parviennent pas à se connecter (ou à publier, s'abonner et recevoir des messages), une autre raison peut être que votre fonction Lambda a dépassé le délai d'attente. Le délai d'expiration de la fonction Lambda pour le mécanisme d'autorisation personnalisé est de 5 secondes. Vous pouvez vérifier la durée de la fonction dans CloudWatch les journaux ou les métriques. ## Enquête sur les problèmes liés aux appareils Si vous ne rencontrez aucun problème lors de l’invocation de votre fonction Lambda ou avec la stratégie renvoyée par la fonction, recherchez les problèmes liés aux tentatives de connexion de vos appareils. Les demandes de connexion mal formées peuvent empêcher AWS IoT Core le déclenchement de votre autorisateur. Des problèmes de connexion peuvent survenir à la fois au niveau des couches TLS et application. **Problèmes possibles avec la couche TLS :** + Les clients doivent transmettre soit un en-tête de nom d'hôte (HTTP, MQTT par-dessus WebSockets), soit l'extension TLS avec indication du nom du serveur (HTTP, MQTT over WebSockets, MQTT) dans toutes les demandes d'authentification personnalisées. Dans les deux cas, la valeur transmise doit correspondre à l'un des points de terminaison de AWS IoT Core données de votre compte. Il s'agit des points de terminaison renvoyés lorsque vous exécutez les commandes CLI suivantes. + `aws iot describe-endpoint --endpoint-type iot:Data-ATS` + `aws iot describe-endpoint --endpoint-type iot:Data`(pour les VeriSign terminaux existants) + Les appareils qui utilisent l’authentification personnalisée pour les connexions MQTT doivent également transmettre l’extension TLS Application Layer Protocol Négociation (ALPN) avec une valeur de `mqtt`. + L'authentification personnalisée est actuellement disponible uniquement sur le port 443. **Problèmes possibles au niveau de la couche application :** + Si la signature est activée (le champ `signingDisabled` est faux dans votre mécanisme d'autorisation), recherchez les problèmes de signature suivants. + Assurez-vous de transmettre la signature du jeton dans l'en-tête `x-amz-customauthorizer-signature` ou dans un paramètre de chaîne de requête. + Assurez-vous que le service ne signe pas une valeur autre que le jeton. + Assurez-vous de transmettre le jeton dans le paramètre d'en-tête ou de requête que vous avez spécifié dans le champ `token-key-name` de votre mécanisme d'autorisation. + Assurez-vous que le nom du mécanisme d'autorisation que vous transmettez dans le paramètre d'en-tête `x-amz-customauthorizer-name` ou de chaîne de requête est valide ou qu'un mécanisme d'autorisation par défaut est défini pour votre compte.