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. # Utilisation des mécanismes d’autorisation Lambda API Gateway Utilisez un *mécanisme d’autorisation Lambda* (anciennement appelé *mécanisme d’autorisation personnalisée*) pour contrôler l’accès à votre API. Lorsqu’un client soumet une méthode sur votre API, API Gateway appelle votre mécanisme d’autorisation Lambda. Ce dernier prend l’identité de l’appelant en entrée et renvoie une politique IAM en sortie. Utilisez un mécanisme d’autorisation Lambda pour implémenter un schéma d’autorisation personnalisée. Votre schéma peut utiliser des paramètres de demande pour déterminer l'identité de l'appelant ou utiliser une stratégie d'authentification par jeton porteur telle que SAML OAuth . Créez un autorisateur Lambda dans la console API REST API Gateway, à l'aide du ou d'un AWS CLI SDK. AWS ## Flux d’autorisation du mécanisme d’autorisation Lambda Le schéma suivant illustre le flux d’autorisation d’un mécanisme d’autorisation Lambda. ![\[Flux de travail d'autorisation Lambda API Gateway\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/custom-auth-workflow.png) **Flux de travail d'autorisation Lambda API Gateway** 1. Le client appelle une méthode sur une API API Gateway, en transmettant un jeton de porteur ou des paramètres de demande. 1. API Gateway vérifie si la demande de méthode est configurée avec un mécanisme d’autorisation Lambda. Si c’est le cas, API Gateway appelle la fonction Lambda. 1. La fonction Lambda authentifie l’appelant. La fonction peut procéder à l’authentification de différentes manières : + En appelant un OAuth fournisseur pour obtenir un jeton OAuth d'accès. + En appelant un fournisseur SAML pour obtenir une assertion SAML. + En générant une politique IAM basée sur les valeurs des paramètres de la demande. + En extrayant les informations d’identification d’une base de données. 1. La fonction Lambda renvoie une politique IAM et un identifiant principal. Si la fonction Lambda ne renvoie pas ces informations, l’appel échoue. 1. API Gateway évalue la politique IAM. + Si l’accès est refusé, API Gateway renvoie un code de statut HTTP approprié, par exemple `403 ACCESS_DENIED`. + Si l’accès est autorisé, API Gateway invoque la méthode. Si vous activez la mise en cache des autorisations, API Gateway met en cache la politique afin que la fonction du mécanisme d’autorisation Lambda ne soit pas invoquée à nouveau. Assurez-vous que votre politique s’applique à toutes les ressources et méthodes de votre API. Vous pouvez personnaliser la réponse de passerelle `403 ACCESS_DENIED` ou `401 UNAUTHORIZED`. Pour en savoir plus, veuillez consulter la section [Réponses de passerelle pour REST APIs dans API Gateway](api-gateway-gatewayResponse-definition.md). ## Choix d’un type de mécanisme d’autorisation Lambda Il existe deux types de mécanismes d’autorisation Lambda : **Mécanisme d’autorisation Lambda basé sur les paramètres de la demande (mécanisme d’autorisation `REQUEST`)** Un mécanisme d’autorisation `REQUEST` reçoit l’identité de l’appelant dans une combinaison d’en-têtes, de paramètres de chaîne de requête, et de variables [`stageVariables`](api-gateway-mapping-template-reference.md#stagevariables-template-reference) et [`$context`](api-gateway-mapping-template-reference.md#context-variable-reference). Vous pouvez utiliser un mécanisme d’autorisation `REQUEST` pour créer des politiques précises basées sur les informations de plusieurs sources d’identité, telles que les variables contextuelles `$context.path` et `$context.httpMethod`. Si vous activez la mise en cache des autorisations pour un mécanisme d’autorisation `REQUEST`, API Gateway vérifie que toutes les sources d’identité spécifiées sont présentes dans la demande. Si une source d’identité spécifiée est absente, nulle ou vide, API Gateway renvoie une réponse HTTP `401 Unauthorized` sans appeler la fonction du mécanisme d’autorisation Lambda. Lorsque plusieurs sources d’identité sont définies, elles sont toutes utilisées pour obtenir la clé de cache du mécanisme d’autorisation, en respectant l’ordre établi. Vous pouvez définir une clé de cache précise en utilisant plusieurs sources d’identité. Si vous modifiez une partie de la clé de cache et redéployez votre API, le mécanisme d’autorisation ignore le document de politique mis en cache et en génère un nouveau. Si vous désactivez la mise en cache des autorisations pour un mécanisme d’autorisation `REQUEST`, API Gateway transmet directement la demande à la fonction Lambda. **Mécanisme d’autorisation Lambda par jeton (mécanisme d’autorisation `TOKEN`)** Un `TOKEN` autorisateur reçoit l'identité de l'appelant dans un jeton porteur, tel qu'un jeton Web JSON (JWT) ou un jeton. OAuth Si vous activez la mise en cache des autorisations pour un mécanisme d’autorisation `TOKEN`, le nom de l’en-tête spécifié dans la source du jeton devient la clé de cache. En outre, vous pouvez utiliser la validation par jeton pour saisir une RegEx déclaration. API Gateway effectue la validation initiale du jeton d’entrée en fonction de cette expression et invoque la fonction du mécanisme d’autorisation Lambda quand la validation aboutit. Cela contribue à réduire le nombre d'appels à votre API. La propriété `IdentityValidationExpression` est prise en charge pour les mécanismes d’autorisation `TOKEN` uniquement. Pour de plus amples informations, veuillez consulter [x-amazon-apigateway-authorizer objet](api-gateway-swagger-extensions-authorizer.md). **Note** Nous vous recommandons d’utiliser un mécanisme d’autorisation `REQUEST` pour contrôler l’accès à votre API. Vous pouvez contrôler l’accès à votre API sur la base de plusieurs sources d’identité lorsque vous utilisez un mécanisme d’autorisation `REQUEST`, alors qu’une seule source d’identité suffit lorsque vous utilisez un mécanisme d’autorisation `TOKEN`. En outre, vous pouvez séparer les clés de cache en utilisant plusieurs sources d’identité pour un mécanisme d’autorisation `REQUEST`. ## Exemple de fonction de mécanisme d’autorisation Lambda `REQUEST` L’exemple de code suivant crée une fonction de mécanisme d’autorisation Lambda qui autorise une demande si l’en-tête `HeaderAuth1` fourni par le client, le paramètre de requête `QueryString1` et la variable d’étape `StageVar1` correspondent aux valeurs `headerValue1`, `queryValue1` et `stageValue1` spécifiées, respectivement. ------ #### [ Node.js ] ``` // A simple request-based authorizer example to demonstrate how to use request // parameters to allow or deny a request. In this example, a request is // authorized if the client-supplied HeaderAuth1 header, QueryString1 // query parameter, and stage variable of StageVar1 all match // specified values of 'headerValue1', 'queryValue1', and 'stageValue1', // respectively. export const handler = function(event, context, callback) { console.log('Received event:', JSON.stringify(event, null, 2)); // Retrieve request parameters from the Lambda function input: var headers = event.headers; var queryStringParameters = event.queryStringParameters; var pathParameters = event.pathParameters; var stageVariables = event.stageVariables; // Parse the input for the parameter values var tmp = event.methodArn.split(':'); var apiGatewayArnTmp = tmp[5].split('/'); var awsAccountId = tmp[4]; var region = tmp[3]; var restApiId = apiGatewayArnTmp[0]; var stage = apiGatewayArnTmp[1]; var method = apiGatewayArnTmp[2]; var resource = '/'; // root resource if (apiGatewayArnTmp[3]) { resource += apiGatewayArnTmp[3]; } // Perform authorization to return the Allow policy for correct parameters and // the 'Unauthorized' error, otherwise. if (headers.HeaderAuth1 === "headerValue1" && queryStringParameters.QueryString1 === "queryValue1" && stageVariables.StageVar1 === "stageValue1") { callback(null, generateAllow('me', event.methodArn)); } else { callback(null, generateDeny('me', event.methodArn)); } } // Help function to generate an IAM policy var generatePolicy = function(principalId, effect, resource) { // Required output: var authResponse = {}; authResponse.principalId = principalId; if (effect && resource) { var policyDocument = {}; policyDocument.Version = '2012-10-17'; // default version policyDocument.Statement = []; var statementOne = {}; statementOne.Action = 'execute-api:Invoke'; // default action statementOne.Effect = effect; statementOne.Resource = resource; policyDocument.Statement[0] = statementOne; authResponse.policyDocument = policyDocument; } // Optional output with custom properties of the String, Number or Boolean type. authResponse.context = { "stringKey": "stringval", "numberKey": 123, "booleanKey": true }; return authResponse; } var generateAllow = function(principalId, resource) { return generatePolicy(principalId, 'Allow', resource); } var generateDeny = function(principalId, resource) { return generatePolicy(principalId, 'Deny', resource); } ``` ------ #### [ Python ] ``` # A simple request-based authorizer example to demonstrate how to use request # parameters to allow or deny a request. In this example, a request is # authorized if the client-supplied headerauth1 header, QueryString1 # query parameter, and stage variable of StageVar1 all match # specified values of 'headerValue1', 'queryValue1', and 'stageValue1', # respectively. def lambda_handler(event, context): print(event) # Retrieve request parameters from the Lambda function input: headers = event['headers'] queryStringParameters = event['queryStringParameters'] pathParameters = event['pathParameters'] stageVariables = event['stageVariables'] # Parse the input for the parameter values tmp = event['methodArn'].split(':') apiGatewayArnTmp = tmp[5].split('/') awsAccountId = tmp[4] region = tmp[3] restApiId = apiGatewayArnTmp[0] stage = apiGatewayArnTmp[1] method = apiGatewayArnTmp[2] resource = '/' if (apiGatewayArnTmp[3]): resource += apiGatewayArnTmp[3] # Perform authorization to return the Allow policy for correct parameters # and the 'Unauthorized' error, otherwise. if (headers['HeaderAuth1'] == "headerValue1" and queryStringParameters['QueryString1'] == "queryValue1" and stageVariables['StageVar1'] == "stageValue1"): response = generateAllow('me', event['methodArn']) print('authorized') return response else: print('unauthorized') response = generateDeny('me', event['methodArn']) return response # Help function to generate IAM policy def generatePolicy(principalId, effect, resource): authResponse = {} authResponse['principalId'] = principalId if (effect and resource): policyDocument = {} policyDocument['Version'] = '2012-10-17' policyDocument['Statement'] = [] statementOne = {} statementOne['Action'] = 'execute-api:Invoke' statementOne['Effect'] = effect statementOne['Resource'] = resource policyDocument['Statement'] = [statementOne] authResponse['policyDocument'] = policyDocument authResponse['context'] = { "stringKey": "stringval", "numberKey": 123, "booleanKey": True } return authResponse def generateAllow(principalId, resource): return generatePolicy(principalId, 'Allow', resource) def generateDeny(principalId, resource): return generatePolicy(principalId, 'Deny', resource) ``` ------ Dans cet exemple, la fonction du mécanisme d’autorisation Lambda vérifie les paramètres d’entrée et agit comme suit : + Si toutes les valeurs de paramètre obligatoires correspondent aux valeurs attendues, la fonction du mécanisme d’autorisation renvoie une réponse HTTP `200 OK` et une politique IAM qui ressemble à ce qui suit, et la demande de la méthode aboutit : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ + Sinon, la fonction du mécanisme d’autorisation renvoie une réponse HTTP `401 Unauthorized` et la demande de méthode échoue. En plus de renvoyer une stratégie IAM, la fonction du mécanisme d'autorisation Lambda doit également renvoyer l'identifiant principal de l'appelant. Elle peut éventuellement renvoyer un objet `context` qui inclut des informations supplémentaires transmissibles au backend d’intégration. Pour de plus amples informations, veuillez consulter [Sortie d’un mécanisme d’autorisation Lambda API Gateway](api-gateway-lambda-authorizer-output.md). Dans le code de production, vous devrez peut-être authentifier l’utilisateur avant d’accorder l’autorisation. Vous pouvez ajouter une logique d’authentification dans la fonction Lambda en appelant un fournisseur d’authentification, comme indiqué dans la documentation de ce fournisseur. ## Exemple de fonction de mécanisme d’autorisation Lambda `TOKEN` L’exemple de code suivant crée une fonction de mécanisme d’autorisation Lambda`TOKEN` qui permet à un appelant d’invoquer une méthode si la valeur du jeton fournie par le client est `allow`. L’appelant n’est pas autorisé à invoquer la demande si la valeur du jeton est `deny`. Si la valeur du jeton est `unauthorized` ou une chaîne vide, la fonction du mécanisme d’autorisation renvoie une réponse `401 UNAUTHORIZED`. ------ #### [ Node.js ] ``` // A simple token-based authorizer example to demonstrate how to use an authorization token // to allow or deny a request. In this example, the caller named 'user' is allowed to invoke // a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke // the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty // string, the authorizer function returns an HTTP 401 status code. For any other token value, // the authorizer returns an HTTP 500 status code. // Note that token values are case-sensitive. export const handler = function(event, context, callback) { var token = event.authorizationToken; switch (token) { case 'allow': callback(null, generatePolicy('user', 'Allow', event.methodArn)); break; case 'deny': callback(null, generatePolicy('user', 'Deny', event.methodArn)); break; case 'unauthorized': callback("Unauthorized"); // Return a 401 Unauthorized response break; default: callback("Error: Invalid token"); // Return a 500 Invalid token response } }; // Help function to generate an IAM policy var generatePolicy = function(principalId, effect, resource) { var authResponse = {}; authResponse.principalId = principalId; if (effect && resource) { var policyDocument = {}; policyDocument.Version = '2012-10-17'; policyDocument.Statement = []; var statementOne = {}; statementOne.Action = 'execute-api:Invoke'; statementOne.Effect = effect; statementOne.Resource = resource; policyDocument.Statement[0] = statementOne; authResponse.policyDocument = policyDocument; } // Optional output with custom properties of the String, Number or Boolean type. authResponse.context = { "stringKey": "stringval", "numberKey": 123, "booleanKey": true }; return authResponse; } ``` ------ #### [ Python ] ``` # A simple token-based authorizer example to demonstrate how to use an authorization token # to allow or deny a request. In this example, the caller named 'user' is allowed to invoke # a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke # the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty # string, the authorizer function returns an HTTP 401 status code. For any other token value, # the authorizer returns an HTTP 500 status code. # Note that token values are case-sensitive. import json def lambda_handler(event, context): token = event['authorizationToken'] if token == 'allow': print('authorized') response = generatePolicy('user', 'Allow', event['methodArn']) elif token == 'deny': print('unauthorized') response = generatePolicy('user', 'Deny', event['methodArn']) elif token == 'unauthorized': print('unauthorized') raise Exception('Unauthorized') # Return a 401 Unauthorized response return 'unauthorized' try: return json.loads(response) except BaseException: print('unauthorized') return 'unauthorized' # Return a 500 error def generatePolicy(principalId, effect, resource): authResponse = {} authResponse['principalId'] = principalId if (effect and resource): policyDocument = {} policyDocument['Version'] = '2012-10-17' policyDocument['Statement'] = [] statementOne = {} statementOne['Action'] = 'execute-api:Invoke' statementOne['Effect'] = effect statementOne['Resource'] = resource policyDocument['Statement'] = [statementOne] authResponse['policyDocument'] = policyDocument authResponse['context'] = { "stringKey": "stringval", "numberKey": 123, "booleanKey": True } authResponse_JSON = json.dumps(authResponse) return authResponse_JSON ``` ------ Dans cet exemple, lorsque l’API reçoit une demande de méthode, API Gateway transmet le jeton source à cette fonction du mécanisme d’autorisation Lambda dans l’attribut `event.authorizationToken`. La fonction du mécanisme d’autorisation Lambda lit le jeton et agit comme suit : + Si la valeur du jeton est `allow`, la fonction du mécanisme d’autorisation renvoie une réponse HTTP `200 OK` et une politique IAM qui ressemble à ce qui suit, et la demande de méthode aboutit : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ + Si la valeur du jeton est `deny`, la fonction du mécanisme d’autorisation renvoie une réponse HTTP `200 OK` et une politique IAM `Deny` qui ressemble à ce qui suit, et la demande de méthode échoue : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Deny", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ **Note** En dehors de l’environnement de test, API Gateway renvoie une réponse HTTP `403 Forbidden` et la demande de méthode échoue. + Si la valeur du jeton est `unauthorized` ou une chaîne vide, la fonction du mécanisme d’autorisation renvoie une réponse HTTP `401 Unauthorized` et l’appel de la méthode échoue. + Si le jeton a n’importe quelle autre valeur, le client reçoit une réponse `500 Invalid token` et l’appel de la méthode échoue. En plus de renvoyer une stratégie IAM, la fonction du mécanisme d'autorisation Lambda doit également renvoyer l'identifiant principal de l'appelant. Elle peut éventuellement renvoyer un objet `context` qui inclut des informations supplémentaires transmissibles au backend d’intégration. Pour de plus amples informations, veuillez consulter [Sortie d’un mécanisme d’autorisation Lambda API Gateway](api-gateway-lambda-authorizer-output.md). Dans le code de production, vous devrez peut-être authentifier l’utilisateur avant d’accorder l’autorisation. Vous pouvez ajouter une logique d’authentification dans la fonction Lambda en appelant un fournisseur d’authentification, comme indiqué dans la documentation de ce fournisseur. ## Exemples supplémentaires de fonctions de mécanisme d’autorisation Lambda La liste suivante présente d’autres exemples de fonctions de mécanisme d’autorisation Lambda. Vous pouvez créer une fonction Lambda dans le même compte, ou dans un autre compte, que celui dans lequel vous avez créé votre API. Dans l'exemple précédent, vous pouvez utiliser les fonctions Lambda intégrées [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html), car ces fonctions n'appellent aucun autre AWS service. Si votre fonction Lambda appelle d'autres AWS services, vous devez attribuer un rôle d'exécution IAM à la fonction Lambda. Pour créer le rôle, suivez les instructions dans [Rôle d’exécution AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html). **Exemples supplémentaires de fonctions de mécanisme d’autorisation Lambda** + Pour un exemple d'application, voir [Open Banking Brésil - Exemples GitHub d'autorisation](https://github.com/aws-samples/openbanking-brazilian-auth-samples) sur. + Pour plus d'exemples de fonctions Lambda, voir [ aws-apigateway-lambda-authorizer-blueprints](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints) on. GitHub + Vous pouvez créer un mécanisme d’autorisation Lambda qui authentifie les utilisateurs à l’aide de groupes d’utilisateurs Amazon Cognito, et autorise les appelants sur la base d’un entrepôt de politiques à l’aide de Verified Permissions. Pour de plus amples informations, veuillez consulter [Contrôle de l’accès sur la base des attributs d’une identité avec Verified Permissions](apigateway-lambda-authorizer-verified-permissions.md). + La console Lambda fournit un plan Python, que vous pouvez utiliser en choisissant **Utiliser un plan puis en choisissant le plan**. **api-gateway-authorizer-python** # Configuration d’un mécanisme d’autorisation Lambda API Gateway Une fois votre fonction Lambda créée, vous allez la configurer en tant que mécanisme d’autorisation pour votre API. Vous allez ensuite configurer votre méthode pour invoquer votre mécanisme d’autorisation Lambda afin de déterminer si un appelant peut invoquer votre méthode. Vous pouvez créer une fonction Lambda dans le même compte, ou dans un autre compte, que celui dans lequel vous avez créé votre API. Vous pouvez tester votre mécanisme d’autorisation Lambda à l’aide des outils intégrés de la console API Gateway ou de [Postman](https://www.postman.com/). Pour apprendre à utiliser Postman pour tester votre fonction de mécanisme d’autorisation Lambda, consultez [Appel d’une API avec un mécanisme d’autorisation Lambda API Gateway](call-api-with-api-gateway-lambda-authorization.md). ## Configuration d’un mécanisme d’autorisation Lambda (console) La procédure suivante montre comment créer un mécanisme d’autorisation Lambda dans la console d’API REST API Gateway. Pour en savoir plus sur les différents types de mécanismes d’autorisation Lambda, consultez [Choix d’un type de mécanisme d’autorisation Lambda](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-choose). ------ #### [ REQUEST authorizer ] **Pour configurer un mécanisme d’autorisation Lambda `REQUEST`** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Sélectionnez une API, puis choisissez **Mécanismes d’autorisation**. 1. Choisissez **Créer un mécanisme d'autorisation**. 1. Pour **Nom du mécanisme d’autorisation**, entrez un nom pour le mécanisme d’autorisation. 1. Pour **Type de mécanisme d'autorisation**, sélectionnez **Lambda**. 1. Pour la **fonction Lambda**, sélectionnez l' Région AWS endroit où vous avez créé votre fonction d'autorisation Lambda, puis entrez le nom de la fonction. 1. Laissez **Rôle d’appel Lambda** vide pour que la console d’API REST API Gateway définisse une politique basée sur les ressources. La politique autorise API Gateway à invoquer la fonction Lambda du mécanisme d’autorisation. Vous pouvez également choisir de saisir le nom d’un rôle IAM pour autoriser API Gateway à invoquer la fonction du mécanisme d’autorisation Lambda. Pour obtenir un exemple de rôle, consultez [Création d’un rôle IAM assumable](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. Pour **Charge utile d’événement Lambda**, sélectionnez **Effectuer une demande**. 1. Pour **Type de source d'identité**, sélectionnez un type de paramètre. Les types de paramètre pris en charge sont `Header`, `Query string`, `Stage variable` et `Context`. Pour ajouter des sources d'identité supplémentaires, choisissez **Ajouter un paramètre**. 1. Pour mettre en cache la politique d'autorisation générée par le mécanisme d'autorisation, maintenez active l'option **Mise en cache des autorisations**. Quand la mise en cache de la politique est activée, vous pouvez modifier la valeur **TTL**. Le fait de définir **TTL** sur zéro désactive la mise en cache de la politique. Si vous activez la mise en cache, votre mécanisme d’autorisation doit renvoyer une politique applicable à toutes les méthodes d’une API. Pour appliquer une politique spécifique à une méthode, utilisez les variables contextuelles `$context.path` et `$context.httpMethod`. 1. Choisissez **Créer un mécanisme d’autorisation**. ------ #### [ TOKEN authorizer ] **Pour configurer un mécanisme d’autorisation Lambda `TOKEN`** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Sélectionnez une API, puis choisissez **Mécanismes d’autorisation**. 1. Choisissez **Créer un mécanisme d'autorisation**. 1. Pour **Nom du mécanisme d’autorisation**, entrez un nom pour le mécanisme d’autorisation. 1. Pour **Type de mécanisme d'autorisation**, sélectionnez **Lambda**. 1. Pour la **fonction Lambda**, sélectionnez l' Région AWS endroit où vous avez créé votre fonction d'autorisation Lambda, puis entrez le nom de la fonction. 1. Laissez **Rôle d’appel Lambda** vide pour que la console d’API REST API Gateway définisse une politique basée sur les ressources. La politique autorise API Gateway à invoquer la fonction Lambda du mécanisme d’autorisation. Vous pouvez également choisir de saisir le nom d’un rôle IAM pour autoriser API Gateway à invoquer la fonction du mécanisme d’autorisation Lambda. Pour obtenir un exemple de rôle, consultez [Création d’un rôle IAM assumable](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. Pour **Charge utile d’événement Lambda**, sélectionnez **Jeton**. 1. Pour **Source de jeton**, entrez le nom de l'en-tête contenant le jeton d'autorisation. L’appelant doit inclure un en-tête portant ce nom pour envoyer le jeton d’autorisation au mécanisme d’autorisation Lambda. 1. (Facultatif) Pour la **validation du jeton**, entrez une RegEx déclaration. API Gateway effectue la validation initiale du jeton d'entrée en fonction de cette expression et appelle le mécanisme d'autorisation quand la validation aboutit. 1. Pour mettre en cache la politique d'autorisation générée par le mécanisme d'autorisation, maintenez active l'option **Mise en cache des autorisations**. Si la mise en cache de la politique est activée, le nom de l'en-tête spécifié dans **Source de jeton** devient la clé de cache. Quand la mise en cache de la politique est activée, vous pouvez modifier la valeur **TTL**. Le fait de définir **TTL** sur zéro désactive la mise en cache de la politique. Si vous activez la mise en cache, votre mécanisme d’autorisation doit renvoyer une politique applicable à toutes les méthodes d’une API. Pour appliquer une politique spécifique à la méthode, vous pouvez désactiver **Mise en cache des autorisations**. 1. Choisissez **Créer un mécanisme d’autorisation**. ------ Une fois que vous avez créé votre mécanisme d’autorisation Lambda, vous pouvez le tester. La procédure suivante montre comment tester votre mécanisme d’autorisation Lambda. ------ #### [ REQUEST authorizer ] **Pour tester un mécanisme d’autorisation Lambda `REQUEST`** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Sélectionnez le nom de votre mécanisme d’autorisation. 1. Sous **Tester le mécanisme d’autorisation**, saisissez une valeur pour votre source d’identité. Si vous utilisez l’[Exemple de fonction de mécanisme d’autorisation Lambda `REQUEST`](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-request-lambda-function-create), procédez comme suit : 1. Sélectionnez **En-tête** et entrez **headerValue1**, puis choisissez **Ajouter un paramètre**. 1. Sous **Type de source d’identité**, sélectionnez **Chaîne de requête** et entrez **queryValue1**, puis choisissez **Ajouter un paramètre**. 1. Sous **Type de source d’identité**, sélectionnez **Variable d’étape** et entrez **stageValue1**. Vous ne pouvez pas modifier les variables contextuelles pour l’invocation de test, mais vous pouvez modifier le modèle d’événement de test **Mécanisme d’autorisation API Gateway** pour votre fonction Lambda. Vous pouvez ensuite tester la fonction de votre mécanisme d’autorisation Lambda avec des variables contextuelles modifiées. Pour plus d’informations, consultez [Testing Lambda functions in the console](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html) dans le *Guide du développeur AWS Lambda *. 1. Choisissez **Tester le mécanisme d'autorisation**. ------ #### [ TOKEN authorizer ] **Pour tester un mécanisme d’autorisation Lambda `TOKEN`** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Sélectionnez le nom de votre mécanisme d’autorisation. 1. Sous **Tester le mécanisme d’autorisation**, saisissez une valeur pour votre jeton. Si vous utilisez l’[Exemple de fonction de mécanisme d’autorisation Lambda `TOKEN`](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-token-lambda-function-create), procédez comme suit : 1. Pour **authorizationToken**, saisissez **allow**. 1. Choisissez **Tester le mécanisme d'autorisation**. Si votre mécanisme d’autorisation Lambda refuse avec succès une demande dans l’environnement de test, le test répond par une réponse HTTP `200 OK`. En revanche, en dehors de l’environnement de test, API Gateway renvoie une réponse HTTP `403 Forbidden` et la demande de méthode échoue. ------ ## Configuration d’un mécanisme d’autorisation Lambda (AWS CLI) La commande [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) suivante montre comment créer un mécanisme d’autorisation Lambda à l’aide de l’ AWS CLI. ------ #### [ REQUEST authorizer ] La commande [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) suivante crée un mécanisme d’autorisation `REQUEST`, et utilise l’en-tête `Authorizer` et la variable de contexte `accountId` comme sources d’identité : ``` aws apigateway create-authorizer \ --rest-api-id 1234123412 \ --name 'First_Request_Custom_Authorizer' \ --type REQUEST \ --authorizer-uri 'arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123412341234:function:customAuthFunction/invocations' \ --identity-source 'method.request.header.Authorization,context.accountId' \ --authorizer-result-ttl-in-seconds 300 ``` ------ #### [ TOKEN authorizer ] La commande [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) suivante crée un mécanisme d’autorisation `TOKEN`, et utilise l’en-tête `Authorization` comme source d’identité : ``` aws apigateway create-authorizer \ --rest-api-id 1234123412 \ --name 'First_Token_Custom_Authorizer' \ --type TOKEN \ --authorizer-uri 'arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123412341234:function:customAuthFunction/invocations' \ --identity-source 'method.request.header.Authorization' \ --authorizer-result-ttl-in-seconds 300 ``` ------ Une fois que vous avez créé votre mécanisme d’autorisation Lambda, vous pouvez le tester. La [test-invoke-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/test-invoke-authorizer.html)commande suivante teste un autorisateur Lambda : ``` aws apigateway test-invoke-authorizer --rest-api-id 1234123412 \ --authorizer-id efg1234 \ --headers Authorization='Value' ``` ## Configuration d’une méthode pour utiliser un mécanisme d’autorisation Lambda (console) Après avoir configuré votre mécanisme d’autorisation Lambda, vous devez l’attacher à une méthode pour votre API. Si votre mécanisme d’autorisation utilise la mise en cache des autorisations, assurez-vous de mettre à jour la politique afin qu’elle contrôle l’accès à la nouvelle méthode. **Pour configurer une méthode d’API pour utiliser un mécanisme d’autorisation Lambda** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Sélectionnez une API. 1. Choisissez **Ressources**, puis sélectionnez une nouvelle méthode ou une méthode existante. 1. Dans l’onglet **Demande de méthode**, sous **Paramètres de requête de méthode**, choisissez **Modifier**. 1. Pour **Mécanisme d’autorisation**, dans le menu déroulant, sélectionnez le mécanisme d’autorisation Lambda que vous venez de créer. 1. (Facultatif) Si vous souhaitez transmettre le jeton d’autorisation au backend, choisissez **En-têtes de demande HTTP**. Choisissez **Ajouter un en-tête**, puis ajoutez le nom de l’en-tête d’autorisation. Pour **Nom**, saisissez le nom de l’en-tête qui correspond au nom **Source du jeton** que vous avez spécifié lorsque vous avez créé le mécanisme d’autorisation Lambda pour l’API. Cette étape ne s’applique pas aux mécanismes d’autorisation `REQUEST`. 1. Choisissez **Enregistrer**. 1. Sélectionnez **Deploy API** pour déployer l’API dans une étape. Pour un mécanisme d’autorisation `REQUEST` utilisant les variables d’étape, vous devez également définir les variables d’étape requises et spécifier leurs valeurs dans la page **Étapes**. ## Configuration d’une méthode pour utiliser un mécanisme d’autorisation Lambda (AWS CLI) Après avoir configuré votre mécanisme d’autorisation Lambda, vous devez l’attacher à une méthode pour votre API. Vous pouvez créer une méthode ou utiliser une opération de correctif pour associer un mécanisme d’autorisation à une méthode existante. Si votre mécanisme d’autorisation utilise la mise en cache des autorisations, assurez-vous de mettre à jour la politique afin qu’elle contrôle l’accès à la nouvelle méthode. La commande [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) suivante crée une méthode utilisant un mécanisme d’autorisation Lambda : ``` aws apigateway put-method --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --authorization-type CUSTOM \ --authorizer-id efg1234 ``` La commande [update-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-method.html) suivante met à jour une méthode existante afin qu’elle utilise un mécanisme d’autorisation Lambda : ``` aws apigateway update-method \ --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --patch-operations op="replace",path="/authorizationType",value="CUSTOM" op="replace",path="/authorizerId",value="efg1234" ``` # Données d’entrée d’un mécanisme d’autorisation Lambda API Gateway La section suivante explique le format de l’entrée envoyée par API Gateway à un mécanisme d’autorisation Lambda. ## Format d'entrée `TOKEN` Pour un mécanisme d’autorisation Lambda (anciennement appelé Custom Authorizer) de type `TOKEN`, vous devez spécifier un en-tête personnalisé comme **Token Source** (Source de jeton) lorsque vous configurez le mécanisme d’autorisation de votre API. Le client de l’API doit transmettre le jeton d’autorisation requis dans l’en-tête de la demande entrante. À réception de la demande de méthode entrante, API Gateway extrait le jeton à partir de l’en-tête personnalisé. Il transmet ensuite le jeton en tant que propriété `authorizationToken` de l’objet `event` de la fonction Lambda, en plus de l’ARN de méthode via la propriété `methodArn` : ``` { "type":"TOKEN", "authorizationToken":"{caller-supplied-token}",     "methodArn":"arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ``` Dans cet exemple, la propriété `type` spécifie le type de mécanisme d’autorisation, à savoir `TOKEN`. La valeur `{caller-supplied-token}` provient de l’en-tête d’autorisation d’une demande client et peut correspondre à n’importe quelle valeur de chaîne. La propriété `methodArn` est l’ARN de la demande de méthode entrante et elle est renseignée par API Gateway conformément à la configuration du mécanisme d’autorisation Lambda. ## Format d'entrée `REQUEST` Pour un mécanisme d’autorisation Lambda de type `REQUEST`, API Gateway transmet les paramètres de demande à la fonction Lambda du mécanisme d’autorisation de l’objet `event`. Les paramètres de demande comprennent les en-têtes, les paramètres des chemins, les paramètres des chaînes d’interrogation, les variables d’étape et certaines variables de contexte de demande. L’appelant de l’API peut définir les paramètres des chemins, les en-têtes et les paramètres des chaînes d’interrogation. Le développeur de l’API doit définir les variables d’étape pendant le déploiement de l’API, et API Gateway fournit le contexte de la demande au moment de l’exécution. **Note** Les paramètres de chemin peuvent être transmis comme paramètres de la demande à la fonction du mécanisme d’autorisation Lambda, mais ils ne peuvent pas être utilisés comme sources d’identité. L’exemple suivant montre les données d’entrée pour un mécanisme d’autorisation `REQUEST` et une méthode d’API (`GET /request`) avec une intégration proxy : ``` { "type": "REQUEST", "methodArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/test/GET/request", "resource": "/request", "path": "/request", "httpMethod": "GET", "headers": { "X-AMZ-Date": "20170718T062915Z", "Accept": "*/*", "HeaderAuth1": "headerValue1", "CloudFront-Viewer-Country": "US", "CloudFront-Forwarded-Proto": "https", "CloudFront-Is-Tablet-Viewer": "false", "CloudFront-Is-Mobile-Viewer": "false", "User-Agent": "..." }, "queryStringParameters": { "QueryString1": "queryValue1" }, "pathParameters": {}, "stageVariables": { "StageVar1": "stageValue1" }, "requestContext": { "path": "/request", "accountId": "123456789012", "resourceId": "05c7jb", "stage": "test", "requestId": "...", "identity": { "apiKey": "...", "sourceIp": "...", "clientCert": { "clientCertPem": "CERT_CONTENT", "subjectDN": "www.example.com", "issuerDN": "Example issuer", "serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1", "validity": { "notBefore": "May 28 12:30:02 2019 GMT", "notAfter": "Aug 5 09:36:04 2021 GMT" } } }, "resourcePath": "/request", "httpMethod": "GET", "apiId": "abcdef123" } } ``` Le contexte `requestContext` est un mappage de paires clé-valeur et correspond à la variable [\$1context](api-gateway-mapping-template-reference.md#context-variable-reference). Son résultat est dépendant de l’API. API Gateway peut ajouter de nouvelles clés au mappage. Pour plus d’informations sur l’entrée de la fonction Lambda dans l’intégration de proxy Lambda, consultez [Format d’entrée d’une fonction Lambda pour l’intégration de proxy](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-input-format). # Sortie d’un mécanisme d’autorisation Lambda API Gateway La sortie de la fonction du mécanisme d’autorisation Lambda est un objet de type dictionnaire, qui doit inclure l’identifiant principal (`principalId`) et un document de politique (`policyDocument`) contenant la liste des déclarations de politique. La sortie peut également inclure un mappage `context` contenant des paires clé-valeur. Si l’API applique un plan d’utilisation ([https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource) est défini sur `AUTHORIZER`), la fonction du mécanisme d’autorisation Lambda doit renvoyer l’une des clés d’API du plan d’utilisation comme valeur de la propriété `usageIdentifierKey`. Voici un exemple de sortie de ce type. ------ #### [ JSON ] **** ``` {   "principalId": "yyyyyyyy", "policyDocument": { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow|Deny", "Resource": "arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ] }, "context": { "stringKey": "value", "numberKey": "1", "booleanKey": "true" }, "usageIdentifierKey": "{api-key}" } ``` ------ Dans cet exemple, une déclaration de politique indique s’il faut permettre ou interdire (`Effect`) au service d’exécution API Gateway d’appeler (`Action`) la méthode d’API spécifiée (`Resource`). Il se peut que vous deviez contrôler l’accès à plusieurs ressources en fonction de votre mécanisme d’autorisation. Vous pouvez utiliser un caractère générique (`*`) pour spécifier un type de ressource (méthode). Pour plus d’informations sur le paramétrage des politiques valides pour appeler une API, consultez [Référence de déclaration de politique IAM pour l’exécution des API dans API Gateway](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-calling-api-permissions). Pour un ARN de méthode activé par autorisation, par exemple `arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]`, la longueur maximale est de 1 600 octets. Les valeurs de paramètre de chemin, dont la taille est déterminée au moment de l’exécution, peuvent entraîner un dépassement de limite de la longueur de l’ARN. Dans ce cas, le client API reçoit une réponse `414 Request URI too long`. De plus, l’ARN de ressources, comme indiqué dans la sortie de déclaration de politique par l’autorisateur, est actuellement limitée à 512 caractères. Pour cette raison, vous ne devez pas utiliser d’URI avec un jeton JWT d’une longueur significative dans une URI de demande. Vous pouvez plutôt transmettre le jeton JWT en toute sécurité dans un en-tête de demande. Vous pouvez accéder à la valeur `principalId` d’un modèle de mappage à l’aide de la variable `$context.authorizer.principalId`. C’est utile si vous souhaitez transmettre la valeur au backend. Pour de plus amples informations, veuillez consulter [Variables context pour les transformations de données](api-gateway-mapping-template-reference.md#context-variable-reference). Vous pouvez accéder à la valeur `stringKey`, `numberKey` ou `booleanKey` (par exemple, `"value"`, `"1"` ou `"true"`) du mappage `context` d’un modèle de mappage en appelant `$context.authorizer.stringKey`, `$context.authorizer.numberKey` ou `$context.authorizer.booleanKey`, respectivement. Les valeurs renvoyées sont toutes obtenues à l’aide de stringify. Notez que vous ne pouvez pas définir un objet ou un tableau JSON comme valeur valide d’une clé dans le mappage `context`. Vous pouvez utiliser le mappage `context` pour renvoyer les informations d’identification mises en cache depuis le mécanisme d’autorisation vers le backend, via un modèle de mappage de demande d’intégration. En exploitant les informations d’identification mises en cache, le backend offre une meilleure expérience utilisateur et évite ainsi d’accéder aux clés secrètes et d’ouvrir des jetons d’autorisation pour chaque demande. Pour l’intégration du proxy Lambda, API Gateway transmet l’objet `context` depuis un mécanisme d’autorisation Lambda directement à la fonction Lambda du backend via l’entrée `event`. Vous pouvez récupérer les paires clé-valeur `context` de la fonction Lambda en appelant `$event.requestContext.authorizer.key`. `{api-key}` représente une clé d’API dans le plan d’utilisation de l’étape d’API. Pour de plus amples informations, veuillez consulter [Plans d'utilisation et clés d'API pour REST APIs dans API Gateway](api-gateway-api-usage-plans.md). L’exemple de mécanisme d’autorisation Lambda renvoie l’exemple de sortie suivant. L'exemple de sortie contient une déclaration de politique visant à bloquer (`Deny`) les appels à la `GET` méthode pour l'`dev`étape d'une API (`ymy8tbxw7b`) d'un AWS compte (`123456789012`). ------ #### [ JSON ] **** ``` { "principalId": "user", "policyDocument": { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Deny", "Resource": "arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/dev/GET/" } ] } } ``` ------ # Appel d’une API avec un mécanisme d’autorisation Lambda API Gateway Après avoir configuré le mécanisme d’autorisation Lambda (anciennement appelé Custom Authorizer) et déployé l’API, vous devez tester l’API avec le mécanisme d’autorisation Lambda activé. Pour cela, vous avez besoin d’un client REST, tel que cURL ou [Postman](https://www.postman.com/). Dans les exemples suivants, nous utilisons Postman. **Note** **Lors de l'appel d'une méthode activée par l'autorisateur, API Gateway n'enregistre pas l'appel CloudWatch si le jeton requis pour l'`TOKEN`autorisateur n'est pas défini, est nul ou est invalidé par l'expression de validation du jeton spécifiée.** De même, API Gateway n'enregistre pas l'appel CloudWatch si l'une des sources d'identité requises pour l'`REQUEST`autorisateur n'est pas définie, est nulle ou est vide. Nous détaillons ci-après comment utiliser Postman pour appeler ou tester une API avec le mécanisme d’autorisation Lambda `TOKEN`. La méthode peut servir à appeler une API avec un mécanisme d’autorisation Lambda `REQUEST` si vous spécifiez le chemin, l’en-tête ou les paramètres des chaînes d’interrogation requis de façon explicite. **Pour appeler une API avec le Custom `TOKEN` Authorizer** 1. Ouvrez **Postman**, sélectionnez la méthode **GET** et collez la valeur du champ **Invoke URL** de l’API dans le champ d’URL adjacent. Ajoutez l’en-tête de jeton d’autorisation Lambda et définissez la valeur `allow`. Sélectionnez **Send (Envoyer)**. ![\[Appel d’une API à l’aide d’un jeton d’autorisation Lambda Allow\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/custom-auth-call-api-with-allow-token.png) La réponse montre que le mécanisme d’autorisation Lambda API Gateway renvoie une réponse **200 OK** et autorise l’appel à accéder au point de terminaison HTTP (http://httpbin.org/get) intégré avec la méthode. 1. Toujours dans l’application Postman, remplacez la valeur de l’en-tête de jeton d’autorisation Lambda par `deny`. Sélectionnez **Send (Envoyer)**. ![\[Appel d’une API à l’aide d’un jeton d’autorisation Lambda Deny\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/custom-auth-call-api-with-deny-token.png) La réponse montre que le mécanisme d’autorisation Lambda API Gateway renvoie une réponse **403 Forbidden (403 Interdit)** sans autoriser l’appel à accéder au point de terminaison HTTP. 1. Dans l’application Postman, remplacez la valeur de l’en-tête de jeton d’autorisation Lambda par `unauthorized`, puis sélectionnez **Send (Envoyer)**. ![\[Appel d’une API à l’aide d’un jeton d’autorisation Lambda Unauthorized\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/custom-auth-call-api-with-unauthorized-token.png) La réponse montre qu’API Gateway renvoie une réponse **401 Unauthorized (401 Accès non autorisé)** sans autoriser l’appel à accéder au point de terminaison HTTP. 1. Maintenant, remplacez la valeur de l’en-tête de jeton d’autorisation Lambda par `fail`. Sélectionnez **Send (Envoyer)**. ![\[Appel d’une API à l’aide d’un jeton d’autorisation Lambda Fail\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/custom-auth-call-api-with-fail-token.png) La réponse montre qu’API Gateway renvoie une réponse **500 Internal Server Error (500 Erreur interne du serveur)** sans autoriser l’appel à accéder au point de terminaison HTTP. # Configuration d’un mécanisme d’autorisation Lambda API Gateway entre comptes Vous pouvez désormais également utiliser une AWS Lambda fonction d'un autre AWS compte comme fonction d'autorisation d'API. Chaque compte peut se trouver dans n’importe quelle région où Amazon API Gateway est disponible. La fonction d'autorisation Lambda peut utiliser des stratégies d'authentification par jeton porteur, telles que SAML. OAuth Cela facilite la gestion et le partage centralisés d'une fonction d'autorisation Lambda centrale entre plusieurs API Gateway. APIs Dans cette section, nous montrons comment configurer une fonction d’autorisation Lambda entre comptes à l’aide de la console Amazon API Gateway. Ces instructions supposent que vous disposez déjà d'une API API Gateway dans un AWS compte et d'une fonction d'autorisation Lambda dans un autre compte. ## Configuration d’un mécanisme d’autorisation Lambda entre comptes à l’aide de la console API Gateway Connectez-vous à la console Amazon API Gateway dans le compte qui contient votre API, puis procédez comme suit : 1. Choisissez votre API, puis dans le panneau de navigation principal, choisissez **Mécanismes d’autorisation**. 1. Choisissez **Créer un mécanisme d'autorisation**. 1. Pour **Nom du mécanisme d’autorisation**, entrez un nom pour le mécanisme d’autorisation. 1. Pour **Type de mécanisme d'autorisation**, sélectionnez **Lambda**. 1. Pour **Fonction Lambda**, entrez l’ARN complet de la fonction de mécanisme d’autorisation Lambda que vous avez dans votre deuxième compte. **Note** Dans la console Lambda, vous trouverez l’ARN de votre fonction dans le coin supérieur droit de la fenêtre de la console. 1. Un avertissement accompagné d’une chaîne de commande `aws lambda add-permission` s’affichera. Cette politique accorde à API Gateway l’autorisation d’invoquer la fonction Lambda de mécanisme d’autorisation. Copiez la commande et enregistrez-la pour plus tard. Vous exécuterez la commande après avoir créé le mécanisme d’autorisation. 1. Pour **Charge utile d’événement Lambda**, sélectionnez **Jeton** pour un mécanisme d’autorisation `TOKEN` ou **Effectuer une demande** pour un mécanisme d’autorisation `REQUEST`. 1. Selon le choix effectué à l’étape précédente, réalisez l’une des actions suivantes : 1. Pour l’option **Jeton**, procédez comme suit : + Pour **Source de jeton**, entrez le nom de l'en-tête contenant le jeton d'autorisation. Le client d’API doit inclure un en-tête portant ce nom pour envoyer le jeton d’autorisation au mécanisme d’autorisation Lambda. + Pour la **validation du jeton**, entrez éventuellement une RegEx instruction. API Gateway effectue la validation initiale du jeton d'entrée en fonction de cette expression et appelle le mécanisme d'autorisation quand la validation aboutit. Cela contribue à réduire le nombre d'appels à votre API. + Pour mettre en cache la politique d'autorisation générée par le mécanisme d'autorisation, maintenez active l'option **Mise en cache des autorisations**. Quand la mise en cache de la politique est activée, vous pouvez choisir de remplacer la valeur **TTL**. Le fait de définir **TTL** sur zéro désactive la mise en cache de la politique. Si la mise en cache de la politique est activée, le nom de l'en-tête spécifié dans **Source de jeton** devient la clé de cache. Si plusieurs valeurs sont transmises à cet en-tête dans la demande, toutes les valeurs deviennent la clé de cache, l’ordre étant préservé. **Note** La valeur **TTL** par défaut est de 300 secondes. Actuellement, sa valeur maximale est de 3 600 secondes ; elle ne peut pas être augmentée. 1. Pour l’option **Request**, effectuez les opérations suivantes : + Pour **Type de source d'identité**, sélectionnez un type de paramètre. Les types de paramètre pris en charge sont `Header`, `Query string`, `Stage variable` et `Context`. Pour ajouter des sources d'identité supplémentaires, choisissez **Ajouter un paramètre**. + Pour mettre en cache la politique d'autorisation générée par le mécanisme d'autorisation, maintenez active l'option **Mise en cache des autorisations**. Quand la mise en cache de la politique est activée, vous pouvez choisir de remplacer la valeur **TTL**. Le fait de définir **TTL** sur zéro désactive la mise en cache de la politique. API Gateway utilise les sources d’identité spécifiées comme clé de mise en cache du mécanisme d’autorisation de la demande. Lorsque la mise en cache est activée, API Gateway appelle la fonction Lambda du mécanisme d’autorisation uniquement si toutes les sources d’identité spécifiées sont présentes lors de l’exécution. Si une source d’identité spécifiée est absente, nulle ou vide, API Gateway renvoie une réponse `401 Unauthorized` sans appeler la fonction Lambda du mécanisme d’autorisation. Lorsque plusieurs sources d’identité sont définies, elles sont toutes utilisées pour obtenir la clé du cache du mécanisme d’autorisation. Si une partie de la clé du cache est modifiée, le mécanisme d’autorisation ignore le document de la politique mis en cache et en génère un nouveau. Si un en-tête à plusieurs valeurs est transmis dans la demande, toutes les valeurs font partie de la clé de cache, l’ordre étant préservé. + Lorsque la mise en cache est désactivée, il n’est pas nécessaire de spécifier une source d’identité. **Note** Pour activer la mise en cache, votre mécanisme d’autorisation doit renvoyer une politique applicable à toutes les méthodes d’une API. Pour appliquer une politique spécifique à la méthode, vous pouvez désactiver **Mise en cache des autorisations**. 1. Choisissez **Créer un mécanisme d'autorisation**. 1. Collez la chaîne de `aws lambda add-permission` commande que vous avez copiée à l'étape précédente dans une AWS CLI fenêtre configurée pour votre deuxième compte. Remplacez `AUTHORIZER_ID` par l’ID de votre mécanisme d’autorisation. Cela permet d’accorder à votre premier compte l’accès à la fonction de mécanisme d’autorisation Lambda de votre deuxième compte. # Contrôle de l’accès sur la base des attributs d’une identité avec Verified Permissions Utilisez Amazon Verified Permissions pour contrôler l’accès à votre API API Gateway. Lorsque vous utilisez API Gateway avec Verified Permissions, Verified Permissions crée un mécanisme d’autorisation Lambda qui utilise des décisions d’autorisation précises pour contrôler l’accès à votre API. Verified Permissions autorise les appelants sur la base d’un schéma d’entrepôt de politiques et de politiques utilisant le langage de politique Cedar pour définir des autorisations précises pour les utilisateurs de l’application. Pour plus d’informations, consultez [Create a policy store with a connected API and identity provider](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/getting-started-api-policy-store.html) dans le *Guide de l’utilisateur Amazon Verified Permissions*. Verified Permissions prend en charge les groupes d’utilisateurs Amazon Cognito ou les fournisseurs d’identité OpenID Connect (OIDC) comme sources d’identité. Verified Permissions présume que le principal a déjà été identifié et authentifié. Les autorisations vérifiées ne sont prises en charge que pour le REST régional et optimisé pour les périphériques. APIs ## Création d’un mécanisme d’autorisation Lambda à l’aide de Verified Permissions Verified Permissions crée un mécanisme d’autorisation Lambda pour déterminer si un principal est autorisé à effectuer une action sur votre API. Vous allez créer la politique Cedar que Verified Permissions utilisera pour effectuer ses tâches d’autorisation. Voici un exemple de politique Cedar qui autorise l’invocation d’une API sur la base du groupe d’utilisateurs Amazon Cognito `us-east-1_ABC1234` pour le groupe `developer` sur la ressource `GET /users` d’une API. Verified Permissions détermine l’appartenance du groupe en recherchant l’identité de l’appelant dans le jeton de porteur. ``` permit( principal in MyAPI::UserGroup::"us-east-1_ABC1234|developer", action in [ MyAPI::Action::"get /users" ], resource ); ``` Verified Permissions peut éventuellement attacher le mécanisme d’autorisation aux méthodes de votre API. Pour les étapes de production de votre API, nous vous recommandons de ne pas autoriser Verified Permissions à attacher le mécanisme d’autorisation à votre place. La liste suivante indique comment configurer Verified Permissions pour qu’il attache ou non le mécanisme d’autorisation Lambda à la demande de méthode envoyée à votre API. **Verified Permissions attache le mécanisme d’autorisation pour vous (AWS Management Console)** Lorsque vous choisissez **Créer un entrepôt de politiques** dans la console Verified Permissions, sur la page **Déployer l’intégration d’application**, sélectionnez **Maintenant**. **Verified Permissions n’attache pas le mécanisme d’autorisation pour vous (AWS Management Console)** Lorsque vous choisissez **Créer un entrepôt de politiques** dans la console Verified Permissions, sur la page **Déployer l’intégration d’application**, sélectionnez **Plus tard**. Verified Permissions crée tout de même un mécanisme d’autorisation Lambda pour vous. Le mécanisme d’autorisation Lambda commence par `AVPAuthorizerLambda-`. Pour apprendre à attacher votre mécanisme d’autorisation à une méthode, consultez [Configuration d’une méthode pour utiliser un mécanisme d’autorisation Lambda (console)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-console). **Verified Permissions attache le mécanisme d’autorisation pour vous (CloudFormation)** Dans le CloudFormation modèle généré par les autorisations vérifiées, dans la `Conditions` section, définissez sur. `"Ref": "shouldAttachAuthorizer"` `true` **Verified Permissions n’attache pas le mécanisme d’autorisation pour vous (CloudFormation)** Dans le CloudFormation modèle généré par les autorisations vérifiées, dans la `Conditions` section, définissez sur. `"Ref": "shouldAttachAuthorizer"` `false` Verified Permissions crée tout de même un mécanisme d’autorisation Lambda pour vous. Le mécanisme d’autorisation Lambda commence par `AVPAuthorizerLambda-`. Pour apprendre à attacher votre mécanisme d’autorisation à une méthode, consultez [Configuration d’une méthode pour utiliser un mécanisme d’autorisation Lambda (AWS CLI)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-cli). ## Appel d’un mécanisme d’autorisation Lambda à l’aide de Verified Permissions Vous pouvez appeler votre mécanisme d’autorisation Lambda en fournissant une identité ou un jeton d’accès dans l’en-tête `Authorization`. Pour de plus amples informations, veuillez consulter [Appel d’une API avec un mécanisme d’autorisation Lambda API Gateway](call-api-with-api-gateway-lambda-authorization.md). API Gateway met en cache la politique renvoyée par votre mécanisme d’autorisation Lambda pendant 120 secondes. Vous pouvez modifier la TTL dans la console API Gateway ou à l’aide de l’ AWS CLI.