

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.

# Sortie d’un mécanisme d’autorisation Lambda API Gateway
<a name="api-gateway-lambda-authorizer-output"></a>

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/"
      }
    ]
  }
}
```

------