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. # Tutoriel : Création d'un autorisateur personnalisé pour AWS IoT Core Ce didacticiel explique les étapes de création, de validation et d'utilisation de l'authentification personnalisée à l'aide du AWS CLI. En option, à l'aide de ce didacticiel, vous pouvez utiliser Postman pour envoyer des données à l'aide de AWS IoT Core de l'API HTTP Publish. Ce didacticiel explique comment créer un exemple de fonction Lambda qui implémente la logique d'autorisation et d'authentification et un mécanisme d'autorisation à l'aide de l'appel **create-authorizer** avec signature par jeton activée. L'autorisateur est ensuite validé à l'aide du**test-invoke-authorizer**, et vous pouvez enfin envoyer des données à AWS IoT Core un sujet MQTT de test à l'aide de l'API HTTP Publish. Un exemple de demande indiquera l'autorisateur à invoquer en utilisant l'`x-amz-customauthorizer-name`en-tête et en transmettant les en-têtes de demande token-key-name et `x-amz-customauthorizer-signature` in. **Ce que vous allez apprendre dans ce didacticiel:** + Comment créer une fonction Lambda en tant que gestionnaire de mécanisme d'autorisation personnalisé + Comment créer un autorisateur personnalisé à l'aide du bouton AWS CLI avec signature par jeton activée + Comment tester votre mécanisme d'autorisation personnalisé à l'aide de la commande **test-invoke-authorizer** + Comment publier une rubrique MQTT à l'aide de [Postman](https://www.postman.com/) et valider la demande avec votre mécanisme d'autorisation personnalisé Ce didacticiel vous prendra environ 60 minutes. **Topics** + [Étape 1 : Créez une fonction Lambda pour votre mécanisme d'autorisation personnalisé](#custom-auth-tutorial-define) + [Étape 2 : Créez une paire de clés publique et privée pour votre mécanisme d’autorisation personnalisé](#custom-auth-tutorial-keys) + [Étape 3 : créer une ressource d'autorisation personnalisée et son autorisation](#custom-auth-tutorial-authorizer) + [Étape 4 : Testez l'autorisateur en appelant test-invoke-authorizer](#custom-auth-tutorial-test) + [Étape 5 : Testez la publication du message MQTT à l'aide de Postman](#custom-auth-tutorial-postman) + [Étape 6 : Afficher les messages dans le client de test MQTT](#custom-auth-tutorial-testclient) + [Étape 7 : examen des résultats et des étapes suivantes](#custom-auth-tutorial-review) + [Étape 8 : nettoyer](#custom-auth-tutorial-cleanup) **Avant de commencer ce didacticiel, assurez-vous de disposer des éléments suivants :** + **[Configurez Compte AWS](setting-up.md)** Vous aurez besoin de votre AWS IoT console Compte AWS et de votre console pour terminer ce didacticiel. Le compte que vous utilisez pour ce didacticiel fonctionne mieux lorsqu'il inclut au moins les politiques AWS gérées suivantes : + [https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/IAMFullAccess$jsonEditor](https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/IAMFullAccess$jsonEditor) + [https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTFullAccess$jsonEditor](https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTFullAccess$jsonEditor) + [https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/AWSLambda_FullAccess$jsonEditor](https://console.aws.amazon.com//iam/home#/policies/arn:aws:iam::aws:policy/AWSLambda_FullAccess$jsonEditor) **Important** Les politiques IAM utilisées dans ce didacticiel sont plus permissives que celles que vous devriez suivre dans le cadre d'une implémentation de production. Dans un environnement de production, assurez-vous que vos politiques de compte et de ressources n'accordent que les autorisations nécessaires. Lorsque vous venez de créer l'Amazon Resource Name (ARN), vous ne pouvez pas supprimer la liste des politiques que les utilisateurs (et les rôles) doivent effectuer et élaborez des politiques leur permettant de réaliser ces tâches. Pour de plus amples informations, veuillez consulter [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html). + **A installé le AWS CLI** Pour plus d'informations sur l'installation de la CLI AWS CLI, reportez-vous à la section [Installation de la AWS CLI](https://docs.aws.amazon.com//cli/latest/userguide/cli-chap-install.html). Ce didacticiel nécessite une AWS CLI version `aws-cli/2.1.3 Python/3.7.4 Darwin/18.7.0 exe/x86_64` ou une version ultérieure. + **Boîte à outils OpenSSL** Les exemples de ce didacticiel utilisent [LibreSSL 2.6.5.](https://www.libressl.org/) Vous pouvez également utiliser les outils [OpenSSL v1.1.1i](https://www.openssl.org/) pour ce didacticiel. + **J'ai revu l'aperçu [AWS Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html)** Si vous ne l'avez jamais utilisé AWS Lambda auparavant, consultez le [AWS Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html)guide [Getting started with Lambda](https://docs.aws.amazon.com//lambda/latest/dg/getting-started.html) pour en apprendre les termes et les concepts. + **J'ai examiné comment créer des demandes dans Postman** Pour plus d'informations, consultez [Demandes de construction](https://learning.postman.com/docs/sending-requests/requests/). + **Autorisateurs personnalisés supprimés du didacticiel précédent** Vous ne Compte AWS pouvez configurer qu'un nombre limité d'autorisateurs personnalisés à la fois. Pour plus d'informations sur la suppression d'un mécanisme d'autorisation personnalisé, consultez [Étape 8 : nettoyer](#custom-auth-tutorial-cleanup). ## Étape 1 : Créez une fonction Lambda pour votre mécanisme d'autorisation personnalisé L'authentification personnalisée AWS IoT Core utilise les [ressources d'autorisation](https://docs.aws.amazon.com//iot/latest/apireference/API_AuthorizerDescription.html) que vous créez pour authentifier et autoriser les clients. La fonction que vous allez créer dans cette section authentifie et autorise les clients lorsqu'ils se connectent aux ressources AWS IoT Core et y accèdent AWS IoT . La fonction Lambda effectue les opérations suivantes : + Si une demande provient de **test-invoke-authorizer**, elle renvoie une politique IAM avec une action `Deny`. + Si une demande provient de Postman via HTTP et que le `actionToken` paramètre a une valeur de`allow`, il renvoie une politique IAM avec une `Allow` action. Dans le cas contraire, il renvoie une politique IAM avec une action `Deny`. **Pour créer une fonction Lambda pour votre mécanisme d'autorisation personnalisé** 1. Dans la console [Lambda](https://console.aws.amazon.com//lambda/home#), ouvrez [Fonctions](https://console.aws.amazon.com//lambda/home#/functions). 1. Choisissez **Créer une fonction**. 1. Confirmez que **l'auteur à partir de zéro (Author from scratch)** est sélectionné. 1. Sous **Basic information** : 1. Sous **Nom de la fonction**, entrez **custom-auth-function**. 1. sSous **Runtime**, confirmez **Node.js 18.x** 1. Choisissez **Créer une fonction**. Lambda crée une fonction Node.js et un [rôle d'exécution](https://docs.aws.amazon.com//lambda/latest/dg/lambda-intro-execution-role.html) qui accorde à la fonction l'autorisation de charger des journaux. La fonction Lambda assume le rôle d'exécution lorsque vous appelez votre fonction et utilise le rôle d'exécution pour créer des informations d'identification pour le AWS SDK et pour lire des données provenant de sources d'événements. 1. Pour voir le code et la configuration de la fonction dans l'[AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)éditeur, choisissez **custom-auth-function**dans la fenêtre du concepteur, puis choisissez **index.js** dans le volet de navigation de l'éditeur. Pour créer une fonction Lambda, sélectionnez l'Amazon Resource Name (ARN) de la fonction Lambda. Node.js Vous pouvez utiliser l'éditeur [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) pour éditer votre fonction tant que votre code source ne dépasse pas 3 Mo. 1. Remplacez le code **index.js** dans l'éditeur par le code suivant : ``` // A simple Lambda function for an authorizer. It demonstrates // How to parse a CLI and Http password to generate a response. export const handler = async (event, context, callback) => { //Http parameter to initiate allow/deny request const HTTP_PARAM_NAME='actionToken'; const ALLOW_ACTION = 'Allow'; const DENY_ACTION = 'Deny'; //Event data passed to Lambda function var event_str = JSON.stringify(event); console.log('Complete event :'+ event_str); //Read protocolData from the event json passed to Lambda function var protocolData = event.protocolData; console.log('protocolData value---> ' + protocolData); //Get the dynamic account ID from function's ARN to be used // as full resource for IAM policy var ACCOUNT_ID = context.invokedFunctionArn.split(":")[4]; console.log("ACCOUNT_ID---"+ACCOUNT_ID); //Get the dynamic region from function's ARN to be used // as full resource for IAM policy var REGION = context.invokedFunctionArn.split(":")[3]; console.log("REGION---"+REGION); //protocolData data will be undefined if testing is done via CLI. // This will help to test the set up. if (protocolData === undefined) { //If CLI testing, pass deny action as this is for testing purpose only. console.log('Using the test-invoke-authorizer cli for testing only'); callback(null, generateAuthResponse(DENY_ACTION,ACCOUNT_ID,REGION)); } else{ //Http Testing from Postman //Get the query string from the request var queryString = event.protocolData.http.queryString; console.log('queryString values -- ' + queryString); /* global URLSearchParams */ const params = new URLSearchParams(queryString); var action = params.get(HTTP_PARAM_NAME); if(action!=null && action.toLowerCase() === 'allow'){ callback(null, generateAuthResponse(ALLOW_ACTION,ACCOUNT_ID,REGION)); }else{ callback(null, generateAuthResponse(DENY_ACTION,ACCOUNT_ID,REGION)); } } }; // Helper function to generate the authorization IAM response. var generateAuthResponse = function(effect,ACCOUNT_ID,REGION) { var full_resource = "arn:aws:iot:"+ REGION + ":" + ACCOUNT_ID + ":*"; console.log("full_resource---"+full_resource); var authResponse = {}; authResponse.isAuthenticated = true; authResponse.principalId = 'principalId'; var policyDocument = {}; policyDocument.Version = '2012-10-17'; policyDocument.Statement = []; var statement = {}; statement.Action = 'iot:*'; statement.Effect = effect; statement.Resource = full_resource; policyDocument.Statement[0] = statement; authResponse.policyDocuments = [policyDocument]; authResponse.disconnectAfterInSeconds = 3600; authResponse.refreshAfterInSeconds = 600; console.log('custom auth policy function called from http'); console.log('authResponse --> ' + JSON.stringify(authResponse)); console.log(authResponse.policyDocuments[0]); return authResponse; } ``` 1. Choisissez **Déployer**. 1. Après le **déploiement des modifications (Changes deployed)** apparaît au-dessus de l'éditeur : 1. Accédez à la section **Vue d'ensemble des fonctions** au-dessus de l'éditeur. 1. Copiez l'**ARN de la fonction** et enregistrez-le pour l'utiliser ultérieurement dans ce didacticiel. 1. Testez votre fonction . 1. Choisissez l’onglet **Test**. 1. À l'aide des paramètres de test par défaut, choisissez **Invoquer**. 1. Si le test a réussi, dans les **résultats de l'exécution**, ouvrez l'aperçu **Détails**. Vous devriez voir le document de politique renvoyé par la fonction. Si le test a échoué ou si aucun document de politique ne s'affiche, examinez le code pour rechercher et corriger les erreurs. ## Étape 2 : Créez une paire de clés publique et privée pour votre mécanisme d’autorisation personnalisé Votre mécanisme d'autorisation personnalisé nécessite une clé publique et privée pour l'authentifier. Les commandes de cette section utilisent les outils OpenSSL pour créer cette paire de clés. **Pour créer une paire de clés publique et privée pour votre mécanisme d’autorisation personnalisé** 1. Créez le fichier de clé privée. ``` openssl genrsa -out private-key.pem 4096 ``` 1. Vérifiez le fichier de clé privée que vous venez de créer. ``` openssl rsa -check -in private-key.pem -noout ``` Si la commande n'affiche aucune erreur, le fichier de clé privée est valide. 1. Créez le fichier de clé publique. ``` openssl rsa -in private-key.pem -pubout -out public-key.pem ``` 1. Vérifiez le fichier de clé publique. ``` openssl pkey -inform PEM -pubin -in public-key.pem -noout ``` Si la commande n'affiche aucune erreur, le fichier de clé publique est valide. ## Étape 3 : créer une ressource d'autorisation personnalisée et son autorisation L'autorisateur AWS IoT personnalisé est la ressource qui réunit tous les éléments créés au cours des étapes précédentes. Dans cette section, vous allez créer une ressource de mécanisme d’autorisation personnalisée et lui donner l'autorisation d'exécuter la fonction Lambda que vous avez créée précédemment. Vous pouvez créer une ressource d'autorisation personnalisée à l'aide de la AWS IoT console AWS CLI, de ou de l' AWS API. Pour ce didacticiel, il vous suffit de créer un seul mécanisme d'autorisation personnalisé. Cette section décrit comment créer à l'aide de la AWS IoT console et du AWS CLI, afin que vous puissiez utiliser la méthode qui vous convient le mieux. Il n'y a aucune différence entre les ressources de mécanisme d'autorisation personnalisées créées par l'une ou l'autre méthode. ### Création d'une ressource d'autorisation personnalisée **Choisissez l'une de ces options pour créer votre ressource de mécanisme d'autorisation personnalisée** + [Créez un autorisateur personnalisé à l'aide de la console AWS IoT](#create-custom-auth-in-console) + [Créer un mécanisme d'autorisation à l'aide de AWS CLI](#create-custom-auth-in-cli) **Pour créer un mécanisme d'autorisation personnalisé (console)** 1. Ouvrez la [page d'autorisation personnalisée de la AWS IoT console, puis choisissez **Create Authorizer**](https://console.aws.amazon.com//iot/home#/authorizerhub). 1. Dans **Créer un mécanisme d'autorisation** 1. Dans **Nom de mécanisme d'autorisation**, entrez **my-new-authorizer**. 1. Dans **État du mécanisme d'autorisation**, cochez **Actif**. 1. Dans **Fonction mécanisme d'autorisation**, choisissez la fonction Lambda que vous avez créée précédemment. 1. Dans **Validation du jeton, facultatif** : 1. Activez la **validation des jetons**. 1. Dans **Nom de la clé du jeton**, entrez**tokenKeyName**. 1. Sélectionnez **Ajouter une clé**. 1. Dans **Key name (Nom de la clé)**, saisissez **FirstKey**. 1. Dans **Clé publique**, entrez le contenu du fichier `public-key.pem`. Veillez à inclure les lignes du fichier dans le contenu du fichier `-----BEGIN PUBLIC KEY-----` et `-----END PUBLIC KEY-----` à ne pas ajouter ou supprimer des fils de ligne, des retours en chariot ou d'autres caractères. La chaîne que vous entrez devrait ressembler à cet exemple. ``` -----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvEBzOk4vhN+3LgslvEWt sLCqNmt5Damas3bmiTRvq2gjRJ6KXGTGQChqArAJwL1a9dkS9+maaXC3vc6xzx9z QPu/vQOe5tyzz1MsKdmtFGxMqQ3qjEXAMPLEOmqyUKPP5mff58k6ePSfXAnzBH0q lg2HioefrpU5OSAnpuRAjYKofKjbc2Vrn6N2G7hV+IfTBvCElf0csalS/Rk4phD5 oa4Y0GHISRnevypg5C8n9Rrz91PWGqP6M/q5DNJJXjMyleG92hQgu1N696bn5Dw8 FhedszFa6b2x6xrItZFzewNQkPMLMFhNrQIIyvshtT/F1LVCS5+v8AQ8UGGDfZmv QeqAMAF7WgagDMXcfgKSVU8yid2sIm56qsCLMvD2Sq8Lgzpey9N5ON1o1Cvldwvc KrJJtgwW6hVqRGuShnownLpgG86M6neZ5sRMbVNZO8OzcobLngJ0Ibw9KkcUdklW gvZ6HEJqBY2XE70iEXAMPLETPHzhqvK6Ei1HGxpHsXx6BNft582J1VpgYjXha8oa /NN7l7Zbj/euAb41IVtmX8JrD9z613d1iM5L8HluJlUzn62Q+VeNV2tdA7MfPfMC 8btGYladFAnitThaz6+F0VSBJPu7pZQoLnqyEp5zLMtF+kFl2yOBmGAP0RBivRd9 JWBUCG0bqcLQPeQyjbXSOfUCAwEAAQ== -----END PUBLIC KEY----- ``` 1. Choisissez **Créer un mécanisme d’autorisation**. 1. Si la ressource du mécanisme d'autorisation personnalisée a été créée, vous verrez la liste des mécanismes d'autorisation personnalisés et votre nouvel mécanisme d'autorisation personnalisé devrait apparaître dans la liste. Vous pouvez passer à la section suivante pour le tester. Si une erreur s'affiche, examinez-la, réessayez de créer votre mécanisme d'autorisation personnalisé et vérifiez les entrées. Notez que chaque ressource de mécanisme d'autorisation personnalisée doit avoir un nom unique. **Pour créer un mécanisme d'autorisation personnalisé (AWS CLI)** 1. Remplacez vos valeurs par `authorizer-function-arn` et `token-signing-public-keys`, puis exécutez la commande suivante : ``` aws iot create-authorizer \ --authorizer-name "my-new-authorizer" \ --token-key-name "tokenKeyName" \ --status ACTIVE \ --no-signing-disabled \ --authorizer-function-arn "arn:aws:lambda:Region:57EXAMPLE833:function:custom-auth-function" \ --token-signing-public-keys FirstKey="-----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvEBzOk4vhN+3LgslvEWt sLCqNmt5Damas3bmiTRvq2gjRJ6KXGTGQChqArAJwL1a9dkS9+maaXC3vc6xzx9z QPu/vQOe5tyzz1MsKdmtFGxMqQ3qjEXAMPLEOmqyUKPP5mff58k6ePSfXAnzBH0q lg2HioefrpU5OSAnpuRAjYKofKjbc2Vrn6N2G7hV+IfTBvCElf0csalS/Rk4phD5 oa4Y0GHISRnevypg5C8n9Rrz91PWGqP6M/q5DNJJXjMyleG92hQgu1N696bn5Dw8 FhedszFa6b2x6xrItZFzewNQkPMLMFhNrQIIyvshtT/F1LVCS5+v8AQ8UGGDfZmv QeqAMAF7WgagDMXcfgKSVU8yid2sIm56qsCLMvD2Sq8Lgzpey9N5ON1o1Cvldwvc KrJJtgwW6hVqRGuShnownLpgG86M6neZ5sRMbVNZO8OzcobLngJ0Ibw9KkcUdklW gvZ6HEJqBY2XE70iEXAMPLETPHzhqvK6Ei1HGxpHsXx6BNft582J1VpgYjXha8oa /NN7l7Zbj/euAb41IVtmX8JrD9z613d1iM5L8HluJlUzn62Q+VeNV2tdA7MfPfMC 8btGYladFAnitThaz6+F0VSBJPu7pZQoLnqyEp5zLMtF+kFl2yOBmGAP0RBivRd9 JWBUCG0bqcLQPeQyjbXSOfUCAwEAAQ== -----END PUBLIC KEY-----" ``` **Où :** + La valeur `authorizer-function-arn` est l'Amazon Resource Name (ARN) de la fonction Lambda que vous avez créée pour votre mécanisme d'autorisation personnalisé. + La valeur `token-signing-public-keys` inclut le nom de la clé **FirstKey** et le contenu du fichier `public-key.pem`. Veillez à inclure les lignes du fichier dans le contenu du fichier `-----BEGIN PUBLIC KEY-----` et `-----END PUBLIC KEY-----` à ne pas ajouter ou supprimer des fils de ligne, des retours en chariot ou d'autres caractères. Remarque : soyez prudent en saisissant la clé publique car toute modification de la valeur de la clé publique la rend inutilisable. 1. Si le mécanisme d'autorisation personnalisé est créé, la commande renvoie le nom et l'ARN de la nouvelle ressource, tels que. ``` { "authorizerName": "my-new-authorizer", "authorizerArn": "arn:aws:iot:Region:57EXAMPLE833:authorizer/my-new-authorizer" } ``` Notez la sortie `authorizerArn` pour l'utiliser lors de l'étape suivante. N'oubliez pas que chaque ressource de mécanisme d'autorisation personnalisée doit avoir un nom unique. ### Autoriser la ressource de mécanisme d'autorisation personnalisée Dans cette section, vous accorderez à la ressource d'autorisation personnalisée que vous venez de créer l'autorisation d'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 une autre valeur si vous avez déjà exécuté ce didacticiel ou si une erreur `ResourceConflictException` s'affiche. ``` 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 ``` ## Étape 4 : Testez l'autorisateur en appelant test-invoke-authorizer Une fois toutes les ressources définies, dans cette section, vous appellerez test-invoke-authorizer depuis la ligne de commande pour tester la passe d'autorisation. Notez que lorsque vous invoquez le mécanisme d’autorisation depuis la ligne de commande, `protocolData` n'est pas défini, de sorte que le mécanisme d’autorisation renvoie toujours un document DENY. Ce test confirme toutefois que votre mécanisme d’autorisation personnalisé et votre fonction Lambda sont correctement configurés, même s'ils ne testent pas complètement la fonction Lambda. **Pour tester votre autorisateur personnalisé et sa fonction Lambda à l'aide du AWS CLI** 1. Dans le répertoire où vous avez créé le fichier `private-key.pem`, entrez la commande suivante. ``` echo -n "tokenKeyValue" | openssl dgst -sha256 -sign private-key.pem | openssl base64 -A ``` Cette commande crée une chaîne de signature à utiliser à l'étape suivante. La chaîne de signature ressemble à ceci : ``` dBwykzlb+fo+JmSGdwoGr8dyC2qB/IyLefJJr+rbCvmu9Jl4KHAA9DG+V+MMWu09YSA86+64Y3Gt4tOykpZqn9mn VB1wyxp+0bDZh8hmqUAUH3fwi3fPjBvCa4cwNuLQNqBZzbCvsluv7i2IMjEg+CPY0zrWt1jr9BikgGPDxWkjaeeh bQHHTo357TegKs9pP30Uf4TrxypNmFswA5k7QIc01n4bIyRTm90OyZ94R4bdJsHNig1JePgnuOBvMGCEFE09jGjj szEHfgAUAQIWXiVGQj16BU1xKpTGSiTAwheLKUjITOEXAMPLECK3aHKYKY+d1vTvdthKtYHBq8MjhzJ0kggbt29V QJCb8RilN/P5+vcVniSXWPplyB5jkYs9UvG08REoy64AtizfUhvSul/r/F3VV8ITtQp3aXiUtcspACi6ca+tsDuX f3LzCwQQF/YSUy02u5XkWn+sto6KCkpNlkD0wU8gl3+kOzxrthnQ8gEajd5Iylx230iqcXo3osjPha7JDyWM5o+K EWckTe91I1mokDr5sJ4JXixvnJTVSx1li49IalW4en1DAkc1a0s2U2UNm236EXAMPLELotyh7h+flFeloZlAWQFH xRlXsPqiVKS1ZIUClaZWprh/orDJplpiWfBgBIOgokJIDGP9gwhXIIk7zWrGmWpMK9o= ``` Copiez cette chaîne de signature pour l'utiliser à l'étape suivante. Veillez à ne pas inclure de caractères supplémentaires ou à ne pas en omettre. 1. Dans cette commande, remplacez la valeur `token-signature` par la chaîne de signature de l'étape précédente et exécutez cette commande pour tester votre mécanisme d’autorisation. ``` aws iot test-invoke-authorizer \ --authorizer-name my-new-authorizer \ --token tokenKeyValue \ --token-signature dBwykzlb+fo+JmSGdwoGr8dyC2qB/IyLefJJr+rbCvmu9Jl4KHAA9DG+V+MMWu09YSA86+64Y3Gt4tOykpZqn9mnVB1wyxp+0bDZh8hmqUAUH3fwi3fPjBvCa4cwNuLQNqBZzbCvsluv7i2IMjEg+CPY0zrWt1jr9BikgGPDxWkjaeehbQHHTo357TegKs9pP30Uf4TrxypNmFswA5k7QIc01n4bIyRTm90OyZ94R4bdJsHNig1JePgnuOBvMGCEFE09jGjjszEHfgAUAQIWXiVGQj16BU1xKpTGSiTAwheLKUjITOEXAMPLECK3aHKYKY+d1vTvdthKtYHBq8MjhzJ0kggbt29VQJCb8RilN/P5+vcVniSXWPplyB5jkYs9UvG08REoy64AtizfUhvSul/r/F3VV8ITtQp3aXiUtcspACi6ca+tsDuXf3LzCwQQF/YSUy02u5XkWn+sto6KCkpNlkD0wU8gl3+kOzxrthnQ8gEajd5Iylx230iqcXo3osjPha7JDyWM5o+KEWckTe91I1mokDr5sJ4JXixvnJTVSx1li49IalW4en1DAkc1a0s2U2UNm236EXAMPLELotyh7h+flFeloZlAWQFHxRlXsPqiVKS1ZIUClaZWprh/orDJplpiWfBgBIOgokJIDGP9gwhXIIk7zWrGmWpMK9o= ``` Si la commande aboutit, elle renvoie les informations générées par votre fonction d'autorisation personnalisée, comme dans cet exemple. ``` { "isAuthenticated": true, "principalId": "principalId", "policyDocuments": [ "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"iot:*\",\"Effect\":\"Deny\",\"Resource\":\"arn:aws:iot:Region:57EXAMPLE833:*\"}]}" ], "refreshAfterInSeconds": 600, "disconnectAfterInSeconds": 3600 } ``` Si la commande renvoie une erreur, vérifiez l'erreur et revérifiez les commandes que vous avez utilisées dans cette section. ## Étape 5 : Testez la publication du message MQTT à l'aide de Postman 1. Pour obtenir le point de terminaison des données de votre appareil depuis la ligne de commande, appelez [describe-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iot/describe-endpoint.html) comme indiqué ici ``` aws iot describe-endpoint --output text --endpoint-type iot:Data-ATS ``` Enregistrez cette adresse pour une utilisation ultérieure. *device\$1data\$1endpoint\$1address* 1. Ouvrez une nouvelle fenêtre Postman et créez une nouvelle requête HTTP POST. 1. Sur votre ordinateur, ouvrez l'application Postman. 1. Dans Postman, dans le menu **File (Fichier)**, choisissez **New… (Nouveau)**. 1. Dans la boîte de dialogue **Nouveau**, choisissez ** Requête**. 1. Dans Enregistrer la requête, 1. Dans **Nom de la requête**, entrez **Custom authorizer test request**. 1. Dans **Sélectionner une collection ou un dossier dans lequel enregistrer** : choisissez ou créez une collection dans laquelle enregistrer cette demande. 1. Choisissez **Enregistrer dans *collection\$1name***. 1. Créez la requête POST pour tester votre mécanisme d’autorisation personnalisé. 1. Dans le sélecteur de méthode de demande situé à côté du champ URL, choisissez **POST**. 1. Dans le champ URL, créez l'URL de votre demande en utilisant l'URL suivante avec la commande *device\$1data\$1endpoint\$1address* from the [describe-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iot/describe-endpoint.html) lors d'une étape précédente. ``` https://device_data_endpoint_address:443/topics/test/cust-auth/topic?qos=0&actionToken=allow ``` Notez que cette URL inclut le paramètre de requête `actionToken=allow` qui indiquera à votre fonction Lambda de renvoyer un document de politique autorisant l'accès à AWS IoT. Après avoir saisi l'URL, les paramètres de requête apparaissent également dans l'onglet Paramètres **Postman.** 1. Dans l'onglet **Auth**, dans le champ **Type**, sélectionnez **No Auth**. 1. Dans la section suivante, passez à l'étape suivante. 1. Si une clé **d'hôte** est cochée, décochez-la. 1. Au bas de la liste des en-têtes, ajoutez ces nouveaux en-têtes et confirmez qu'ils sont cochés. Remplacez la **Host** valeur par votre *device\$1data\$1endpoint\$1address* et la **x-amz-customauthorizer-signature** valeur par la chaîne de signature que vous avez utilisée avec la **test-invoke-authorize** commande de la section précédente. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/custom-auth-tutorial.html) 1. Dans l'onglet Body : 1. Dans la zone d'option du format des données, choisissez **Raw**. 1. Dans la liste des types de données, sélectionnez **JavaScript**. 1. Dans le champ de texte, entrez la charge utile du message JSON pour votre message de test : ``` { "data_mode": "test", "vibration": 200, "temperature": 40 } ``` 1. Choisissez **Send** pour envoyer la requête. Si la requête aboutit, elle renvoie : ``` { "message": "OK", "traceId": "ff35c33f-409a-ea90-b06f-fbEXAMPLE25c" } ``` La réponse positive indique que votre autorisateur personnalisé a autorisé la connexion à AWS IoT et que le message de test a été remis au broker in AWS IoT Core. S'il renvoie une erreur, consultez le message d'erreur*device\$1data\$1endpoint\$1address*, la chaîne de signature et les autres valeurs d'en-tête. Conservez cette demande dans Postman pour l'utiliser dans la section suivante. ## Étape 6 : Afficher les messages dans le client de test MQTT À l'étape précédente, vous avez envoyé des messages simulés à un appareil à l'aide AWS IoT de Postman. La réponse positive indique que votre mécanisme d’autorisation personnalisé a autorisé la connexion à AWS IoT et que le message de test a été livré au courtier en AWS IoT Core. Dans cette section, vous allez utiliser le client de test MQTT de la AWS IoT console pour voir le contenu du message, comme le feraient d'autres appareils et services. **Pour voir les messages de test autorisés par votre mécanisme d’autorisation personnalisé** 1. Dans la AWS IoT console, ouvrez le [client de test MQTT](https://console.aws.amazon.com//iot/home#/test). 1. Dans l'onglet **S'abonner à la rubrique**, dans le **filtre de rubrique****test/cust-auth/topic**, entrez la rubrique du message utilisé dans l'exemple Postman de la section précédente. 1. Choisissez **Abonner**. Gardez cette fenêtre visible pour l'étape suivante. 1. Dans Postman, dans la demande que vous avez créée pour la section précédente, choisissez **Envoyer**. Passez en revue la réponse pour vous assurer qu'elle a bien été prise en compte. Si ce n'est pas le cas, corrigez l'erreur comme décrit dans la section précédente. 1. Dans le **client de test MQTT**, vous devriez voir une nouvelle entrée indiquant la rubrique du message et, s'il est développé, la charge utile du message provenant de la demande que vous avez envoyée depuis Postman. Si vous ne voyez pas vos messages dans le **client de test MQTT**, voici quelques points à vérifier : + Assurez-vous que votre demande Postman a été renvoyée avec succès. En cas de AWS IoT rejet de la connexion et de renvoi d'une erreur, le message contenu dans la demande n'est pas transmis au courtier de messages. + Assurez-vous que le Compte AWS et Région AWS utilisé pour ouvrir la AWS IoT console sont les mêmes que ceux que vous utilisez dans l'URL du Postman. + Assurez-vous que vous utilisez le point de terminaison approprié pour l'autorisateur personnalisé. 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é. + Assurez-vous d'avoir correctement saisi la rubrique dans le **client de test MQTT**. Le filtre de sujet est sensible à la casse. En cas de doute, vous pouvez également vous abonner à la **\$1** rubrique, qui s'abonne à tous les messages MQTT qui passent par le courtier de messages Compte AWS et Région AWS utilisés pour ouvrir la AWS IoT console. ## Étape 7 : examen des résultats et des étapes suivantes **Dans ce tutoriel :** + Vous avez créé une fonction Lambda pour être un gestionnaire de mécanisme d'autorisation personnalisé + Vous avez créé un mécanisme d'autorisation personnalisé avec la signature par jeton activée + Vous avez testé votre mécanisme d'autorisation personnalisé à l'aide de la commande **test-invoke-authorizer** + Vous avez publié une rubrique MQTT à l'aide de [Postman](https://www.postman.com/) et valider la demande avec votre mécanisme d'autorisation personnalisé + Vous avez utilisé le **client de test MQTT** pour visualiser les messages envoyés depuis votre test Postman **Étapes suivantes** Après avoir envoyé des messages de Postman pour vérifier que le mécanisme d’autorisation personnalisé fonctionne, essayez d'expérimenter pour voir comment la modification des différents aspects de ce didacticiel affecte les résultats. Voici quelques exemples pour vous aider à démarrer. + Modifiez la chaîne de signature afin qu'elle ne soit plus valide pour voir comment les tentatives de connexion non autorisées sont traitées. Vous devriez obtenir une réponse d'erreur, comme celle-ci, et le message ne devrait pas apparaître dans le **client de test MQTT**. ``` { "message": "Forbidden", "traceId": "15969756-a4a4-917c-b47a-5433e25b1356" } ``` + Pour en savoir plus sur la façon de détecter les erreurs susceptibles de se produire lors du développement et de l'utilisation de AWS IoT règles, consultez[Surveillance AWS IoT](monitoring_overview.md). ## Étape 8 : nettoyer Si vous souhaitez répéter ce didacticiel, vous devrez peut-être supprimer certains de vos mécanismes d’autorisation personnalisés. Vous ne Compte AWS pouvez configurer qu'un nombre limité d'autorisateurs personnalisés à la fois et vous pouvez en obtenir un `LimitExceededException` lorsque vous essayez d'en ajouter un nouveau sans supprimer un autorisateur personnalisé existant. **Pour supprimer un mécanisme d'autorisation personnalisé (console)** 1. Ouvrez la [page d'autorisation personnalisée de la AWS IoT console](https://console.aws.amazon.com//iot/home#/authorizerhub) et, dans la liste des autorisateurs personnalisés, recherchez l'autorisateur personnalisé à supprimer. 1. Ouvrez la page de détails de mécanisme d’autorisation personnalisé et, dans le menu **Actions**, choisissez **Modifier**. 1. Décochez la case **Activer l'autorisateur**, puis choisissez **Mettre à jour**. Vous ne pouvez pas supprimer un mécanisme d'autorisation personnalisé lorsqu'il est actif. 1. Sur la page Détails du mécanisme d’autorisation personnalisé, ouvrez le menu **Actions** et choisissez **Supprimer**. **Pour supprimer un mécanisme d'autorisation personnalisé (AWS CLI)** 1. Répertoriez les mécanismes d’autorisation personnalisées que vous avez installées et recherchez ceux que vous souhaitez supprimer. ``` aws iot list-authorizers ``` 1. Définissez le mécanisme d'autorisation personnalisé sur `inactive` en exécutant cette commande après avoir remplacé `Custom_Auth_Name` par `authorizerName` du mécanisme d'autorisation personnalisé à supprimer. ``` aws iot update-authorizer --status INACTIVE --authorizer-name Custom_Auth_Name ``` 1. Supprimez le mécanisme d'autorisation personnalisé `Custom_Auth_Name` en exécutant cette commande après avoir remplacé `authorizerName` par du mécanisme d'autorisation personnalisé à supprimer. ``` aws iot delete-authorizer --authorizer-name Custom_Auth_Name ```