# Uso de autorizadores Lambda de API Gateway Utilice un *autorizador de Lambda* (que anteriormente se denominaba *autorizador personalizado*) para controlar el acceso a su API. Cuando un cliente realiza una solicitud al método de la API, API Gateway llama al autorizador de Lambda. El autorizador de Lambda toma la identidad del intermediario como entrada y devuelve una política de IAM como salida. Utilice un autorizador de Lambda para implementar un esquema de autorización personalizado. El esquema puede utilizar los parámetros de la solicitud para determinar la identidad del intermediario o utilizar una estrategia de autenticación de token de portador como OAuth o SAML. Cree un autorizador de Lambda en la consola de la API de REST de API Gateway mediante la AWS CLI o un SDK de AWS. ## Flujo del trabajo de autorización del autorizador de Lambda El siguiente diagrama muestra el flujo de trabajo de autorización para un autorizador de Lambda. ![\[Flujo de trabajo de autorización de Lambda en API Gateway\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/custom-auth-workflow.png) **Flujo de trabajo de autorización de Lambda en API Gateway** 1. El cliente llama a un método en una API de API Gateway, pasando un token de portador o parámetros de solicitud. 1. API Gateway comprueba si la solicitud de método está configurada con un autorizador de Lambda. Si es así, API Gateway llama a la función de Lambda. 1. La función de Lambda autentica al intermediario. La función puede autenticarse de una de las siguientes formas: + Llamando a un proveedor de OAuth para obtener un token de acceso de OAuth. + Llamando a un proveedor de SAML para obtener una aserción de SAML. + Generando una política de IAM basada en los valores de los parámetros de la solicitud. + Recuperando credenciales de una base de datos. 1. La función de Lambda devuelve una política de IAM y un identificador de entidad principal. Si la función de Lambda no devuelve esa información, se produce un error en la llamada. 1. API Gateway evalúa la política de IAM. + Si se deniega el acceso, API Gateway devuelve un código de estado HTTP apropiado, como por ejemplo `403 ACCESS_DENIED`. + Si se permite el acceso, API Gateway invoca el método. Si habilita el almacenamiento en caché de la autorización, API Gateway almacena en caché la política de modo que no es necesario volver a invocar la función del autorizador de Lambda. Asegúrese de que la política se aplique a todos los recursos y métodos de la API. Puede personalizar las respuestas de la puerta de enlace `403 ACCESS_DENIED` o `401 UNAUTHORIZED`. Para obtener más información, consulte [Respuestas de Gateway para las API de REST en API Gateway](api-gateway-gatewayResponse-definition.md). ## Elección de un tipo de autorizador de Lambda Hay dos tipos de autorizadores Lambda: **Autorizador de Lambda basado en parámetros de solicitud (autorizador `REQUEST`)** Un autorizador `REQUEST` recibe la identidad de la persona que llama en una combinación de encabezados, parámetros de cadenas de consulta, [`stageVariables`](api-gateway-mapping-template-reference.md#stagevariables-template-reference) y variables [`$context`](api-gateway-mapping-template-reference.md#context-variable-reference). Puede usar un autorizador `REQUEST` para crear políticas detalladas basadas en la información de varios orígenes de identidad, como las variables de contexto `$context.path` y `$context.httpMethod`. Si activa el almacenamiento en caché de autorizaciones para un autorizador `REQUEST`, API Gateway verifica que todos los orígenes de identidad especificados estén presentes en la solicitud. Si falta algún origen de identidad especificado, o bien es nulo o está vacío, API Gateway devolverá una respuesta HTTP `401 Unauthorized` sin llamar a la función del autorizador de Lambda. Cuando se definen varios orígenes de identidad, se utilizan todos para obtener la clave de caché del autorizador, manteniendo el mismo orden. Puede definir una clave de caché detallada mediante el uso de varios orígenes de identidad. Si cambia cualquiera de las partes de la clave de caché y vuelve a implementar su API, el autorizador descartará el documento de políticas almacenado en caché y generará otro nuevo. Si desactiva el almacenamiento en caché de autorizaciones para un autorizador `REQUEST`, API Gateway pasa directamente la solicitud a la función de Lambda. **Autorizador de Lambda basado en token (autorizador `TOKEN`)** Un autorizador `TOKEN` recibe la identidad del intermediario en un token de portador, como, por ejemplo, un JSON Web Token (JWT) o un token de OAuth. Si activa el almacenamiento en caché de autorizaciones para un autorizador `TOKEN`, el nombre del encabezado especificado en el origen del token pasará a ser la clave de caché. Además, puede utilizar la validación del token para introducir una instrucción RegEx. API Gateway realiza la validación inicial del token de entrada con respecto a esta expresión e invoca la función del autorizador de Lambda tras una validación correcta. Esto ayuda a reducir las llamadas a la API. La propiedad `IdentityValidationExpression` solo es compatible con autorizadores `TOKEN`. Para obtener más información, consulte [Objeto x-amazon-apigateway-authorizer](api-gateway-swagger-extensions-authorizer.md). **nota** Le recomendamos que utilice un autorizador `REQUEST` para controlar el acceso a su API. Puede controlar el acceso a su API en función de varios orígenes de identidad al utilizar un autorizador `REQUEST`, en comparación con un único origen de identidad al utilizar un autorizador `TOKEN`. Además, puede separar las claves de caché utilizando varios orígenes de identidad para un autorizador `REQUEST`. ## Ejemplo de función de Lambda con un autorizador `REQUEST` El siguiente código de ejemplo crea una función del autorizador de Lambda que permite realizar una solicitud si el encabezado `HeaderAuth1`, el parámetro de consulta `QueryString1` y la variable de etapa de `StageVar1` proporcionados por el cliente coinciden con los valores especificados de `headerValue1`, `queryValue1` y `stageValue1` respectivamente. ------ #### [ 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) ``` ------ En este ejemplo, la función del autorizador de Lambda comprueba los parámetros de entrada y actúa como se indica a continuación: + Si todos los valores de los parámetros necesarios coinciden con los valores previstos, la función del autorizador devuelve una respuesta HTTP `200 OK` y una política de IAM que tiene un aspecto similar al siguiente, y la solicitud del método se lleva a cabo correctamente: ------ #### [ 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/" } ] } ``` ------ + De lo contrario, la función del autorizador devuelve una respuesta HTTP `401 Unauthorized` y la solicitud al método produce un error. Además de devolver una política de IAM, la función del autorizador de Lambda también debe devolver el identificador principal del intermediario. Opcionalmente, puede devolver un objeto `context`, que contiene información adicional que puede pasarse al backend de integración. Para obtener más información, consulte [Salida de un autorizador de Lambda de API Gateway](api-gateway-lambda-authorizer-output.md). En el código de producción, es posible que necesite autenticar al usuario antes de conceder la autorización. En tal caso, puede agregar la lógica de autenticación a la función de Lambda llamando a un proveedor de autenticación de la forma que se indica en la documentación de ese proveedor. ## Ejemplo de función de Lambda con un autorizador `TOKEN` El siguiente código de ejemplo crea una función del autorizador de Lambda `TOKEN` que permite al intermediario invocar un método si el valor del token proporcionado por el cliente es `allow`. El intermediario no puede invocar la solicitud si el valor del token es `deny`. Si el valor del token es `unauthorized` o una cadena vacía, la función del autorizador devolverá una respuesta `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 ``` ------ En este ejemplo, cuando la API recibe una solicitud de método, API Gateway pasa el token de origen a esta función de autorizador de Lambda en el atributo `event.authorizationToken`. La función del autorizador de Lambda lee el token y actúa como se indica a continuación: + Si el valor del token es `allow`, la función del autorizador devuelve una respuesta HTTP `200 OK` y una política de IAM que tiene un aspecto similar al siguiente, y la solicitud del método se lleva a cabo correctamente: ------ #### [ 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 el valor del token es `deny`, la función del autorizador devolverá una respuesta HTTP `200 OK` y una política `Deny` de IAM similar a la siguiente y se producirá un error en la solicitud del método: ------ #### [ 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/" } ] } ``` ------ **nota** Fuera del entorno de prueba, API Gateway devuelve una respuesta HTTP `403 Forbidden` y la solicitud del método produce un error. + Si el valor del token es `unauthorized` o una cadena vacía, la función del autorizador devolverá una respuesta HTTP `401 Unauthorized` y la llamada al método producirá un error. + Si el token es cualquier otra cosa, el cliente recibirá una respuesta `500 Invalid token` y la llamada al método producirá un error. Además de devolver una política de IAM, la función del autorizador de Lambda también debe devolver el identificador principal del intermediario. Opcionalmente, puede devolver un objeto `context`, que contiene información adicional que puede pasarse al backend de integración. Para obtener más información, consulte [Salida de un autorizador de Lambda de API Gateway](api-gateway-lambda-authorizer-output.md). En el código de producción, es posible que necesite autenticar al usuario antes de conceder la autorización. En tal caso, puede agregar la lógica de autenticación a la función de Lambda llamando a un proveedor de autenticación de la forma que se indica en la documentación de ese proveedor. ## Ejemplos adicionales de funciones del autorizador de Lambda En la siguiente lista, se muestran ejemplos adicionales de funciones del autorizador de Lambda. Puede crear una función de Lambda en la misma cuenta desde la que creó la API o en una cuenta diferente. Para las funciones de Lambda del ejemplo anterior, puede utilizar el [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) integrado, ya que estas funciones no llaman a otros servicios de AWS. Si su función de Lambda llama a otros servicios de AWS, tendrá que asignar un rol de ejecución de IAM para la función de Lambda. Para crear el rol, siga las instrucciones de [Rol de ejecución de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html). **Ejemplos adicionales de funciones del autorizador de Lambda** + Para ver una aplicación de ejemplo, consulte [Open Banking Brazil - Ejemplos de autorización](https://github.com/aws-samples/openbanking-brazilian-auth-samples) en GitHub. + Para ver más ejemplos de funciones de Lambda, consulte [aws-apigateway-lambda-authorizer-blueprints](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints) en GitHub. + Puede crear un autorizador de Lambda que autentique a los usuarios mediante grupos de usuarios de Amazon Cognito y autorice a los intermediarios en función de un almacén de políticas mediante permisos verificados. Para obtener más información, consulte [Control del acceso en función de los atributos de una identidad con Verified Permissions](apigateway-lambda-authorizer-verified-permissions.md). + La consola de Lambda ofrece un proyecto de Python, que se puede utilizar eligiendo **Use a blueprint (Utilizar un proyecto)** y eligiendo el proyecto **api-gateway-authorizer-python**. # Configuración de un autorizador de Lambda de API Gateway Tras crear una función de Lambda, debe configurarla como un autorizador para su API. A continuación, configure su método para invocar su autorizador de Lambda y determinar si un intermediario puede invocar su método. Puede crear una función de Lambda en la misma cuenta desde la que creó la API o en una cuenta diferente. Puede probar su autorizador de Lambda mediante las herramientas integradas en la consola de API Gateway o con [Postman](https://www.postman.com/). Para obtener instrucciones sobre cómo usar Postman para probar la función del autorizador de Lambda, consulte [Llamada a una API con un autorizador de Lambda de API Gateway](call-api-with-api-gateway-lambda-authorization.md). ## Configuración de un autorizador de Lambda (consola) El siguiente procedimiento muestra cómo crear un autorizador de Lambda en la consola de la API de REST de API Gateway. Para obtener más información sobre los distintos tipos de autorizadores de Lambda, consulte [Elección de un tipo de autorizador de Lambda](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-choose). ------ #### [ REQUEST authorizer ] **Configuración de un autorizador de Lambda `REQUEST`** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione una API y, a continuación, elija **Autorizadores**. 1. Elija **Crear autorizador**. 1. En **Nombre del autorizador**, ingrese un nombre para el autorizador. 1. En **Tipo de autorizador**, seleccione **Lambda**. 1. En **Función de Lambda**, seleccione la Región de AWS en la que creó la función de autorizador de Lambda y, a continuación, ingrese el nombre de la función. 1. Deje en blanco **Rol de invocación de Lambda** para permitir que la consola de la API de REST de API Gateway defina una política basada en recursos. La política concede permisos a API Gateway para invocar la función del autorizador de Lambda. También puede escribir el nombre de un rol de IAM para permitir que API Gateway invoque la función del autorizador de Lambda. Para ver un rol de ejemplo, consulte [Crear un rol de IAM asumible](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. En **Carga de evento de Lambda**, seleccione **Solicitud**. 1. En **Tipo de origen de identidades**, seleccione un tipo de parámetro. Los tipos de parámetro admitidos son `Header`, `Query string`, `Stage variable` y `Context`. Para agregar más orígenes de identidades, elija **Agregar parámetro**. 1. Para almacenar en caché la política de autorización generada por el autorizador, mantenga activado **Almacenamiento en caché de la autorización**. Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor **TTL**. Si establece **TTL** en cero se desactivará el almacenamiento en caché de políticas. Si habilita el almacenamiento en caché, su autorizador debe devolver una política que se aplique a todos los métodos a través de una API. Para aplicar una política específica de un método, utilice las variables de contexto `$context.path` y `$context.httpMethod`. 1. Elija **Crear autorizador**. ------ #### [ TOKEN authorizer ] **Configuración de un autorizador de Lambda `TOKEN`** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione una API y, a continuación, elija **Autorizadores**. 1. Elija **Crear autorizador**. 1. En **Nombre del autorizador**, ingrese un nombre para el autorizador. 1. En **Tipo de autorizador**, seleccione **Lambda**. 1. En **Función de Lambda**, seleccione la Región de AWS en la que creó la función de autorizador de Lambda y, a continuación, ingrese el nombre de la función. 1. Deje en blanco **Rol de invocación de Lambda** para permitir que la consola de la API de REST de API Gateway defina una política basada en recursos. La política concede permisos a API Gateway para invocar la función del autorizador de Lambda. También puede escribir el nombre de un rol de IAM para permitir que API Gateway invoque la función del autorizador de Lambda. Para ver un rol de ejemplo, consulte [Crear un rol de IAM asumible](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. En **Carga de evento de Lambda**, seleccione **Token**. 1. En **Origen del token**, ingrese el nombre del encabezado que contiene el token de autorización. El intermediario debe incluir un encabezado con este nombre para enviar el token de autorización al autorizador de Lambda. 1. (Opcional) Si lo desea, en **Validación del token**, introduzca una instrucción RegEx. API Gateway realiza la validación inicial del token de entrada contra esta expresión e invoca el autorizador tras una validación correcta. 1. Para almacenar en caché la política de autorización generada por el autorizador, mantenga activado **Almacenamiento en caché de la autorización**. Cuando el almacenamiento en caché de las políticas esté habilitado, el nombre del encabezado especificado en **Origen del token** pasará a ser la clave de caché. Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor **TTL**. Si establece **TTL** en cero se desactivará el almacenamiento en caché de políticas. Si habilita el almacenamiento en caché, su autorizador debe devolver una política que se aplique a todos los métodos a través de una API. Para aplicar una política específica de un método, puede desactivar **Almacenamiento en caché de autorización**. 1. Elija **Crear autorizador**. ------ Después de crear el autorizador de Lambda, puede probarlo. El siguiente procedimiento muestra cómo probar el autorizador de Lambda. ------ #### [ REQUEST authorizer ] **Prueba de un autorizador de Lambda `REQUEST`** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione el nombre del autorizador. 1. En **Probar autorizador**, introduzca un valor para su origen de identidad. Si utiliza la [Ejemplo de función de Lambda con un autorizador `REQUEST`](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-request-lambda-function-create), haga lo siguiente: 1. Seleccione **Encabezado** e ingrese **headerValue1** y, a continuación, elija **Agregar parámetro**. 1. En **Tipo de origen de identidades**, seleccione **Cadena de consulta** e ingrese **queryValue1** y, a continuación, elija **Agregar parámetro**. 1. En **Tipo de origen de identidades**, seleccione **Variable de etapa** e ingrese **stageValue1**. No puede modificar las variables de contexto para la invocación de la prueba, pero sí puede modificar la plantilla de eventos de prueba del **Autorizador de API Gateway** para la función de Lambda. A continuación, puede probar la función del autorizador de Lambda con variables de contexto modificadas. Para obtener más información, consulte [Prueba de funciones de Lambda en la consola](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html) en la *Guía para desarrolladores de AWS Lambda*. 1. Elija **Probar el autorizador**. ------ #### [ TOKEN authorizer ] **Prueba de un autorizador de Lambda `TOKEN`** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione el nombre del autorizador. 1. En **Probar autorizador**, introduzca un valor para su token. Si utiliza la [Ejemplo de función de Lambda con un autorizador `TOKEN`](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-token-lambda-function-create), haga lo siguiente: 1. En **authorizationToken**, especifique **allow**. 1. Elija **Probar el autorizador**. Si el autorizador de Lambda rechaza correctamente una solicitud en el entorno de prueba, la prueba produce una respuesta HTTP `200 OK`. Sin embargo, fuera del entorno de prueba, API Gateway devuelve una respuesta HTTP `403 Forbidden` y la solicitud del método produce un error. ------ ## Configuración de un autorizador de Lambda (AWS CLI) El siguiente comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) muestra cómo crear un autorizador de Lambda mediante la AWS CLI. ------ #### [ REQUEST authorizer ] El siguiente comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) permite crear un autorizador de `REQUEST`, y utiliza el encabezado `Authorizer` y la variable de contexto `accountId` como orígenes de identidad: ``` 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 ] El siguiente comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) permite crear un autorizados de `TOKEN`, y utiliza el encabezado `Authorization` como origen de identidad: ``` 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 ``` ------ Después de crear el autorizador de Lambda, puede probarlo. El siguiente comando [test-invoke-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/test-invoke-authorizer.html) permite probar un autorizador de Lambda: ``` aws apigateway test-invoke-authorizer --rest-api-id 1234123412 \ --authorizer-id efg1234 \ --headers Authorization='Value' ``` ## Configuración de un método para utilizar un autorizador de Lambda (consola) Después de configurar el autorizador de Lambda, debe asociarlo a un método para la API. Si el autorizador utiliza el almacenamiento en caché de la autorización, asegúrese de actualizar la política para controlar el acceso del método adicional. **Para configurar un método de API para que use un autorizador de Lambda** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione una API. 1. Elija **Recursos** y seleccione un método nuevo o elija un método existente. 1. En la pestaña **Solicitud de método**, en **Configuración de solicitud de método**, elija **Editar**. 1. En **Autorizador**, en el menú desplegable, seleccione el autorizador de Lambda que acaba de crear. 1. (Opcional) Si quiere pasar el token de autorización al backend, elija los **encabezados de solicitud HTTP**. Elija **Agregar encabezado** y, a continuación, agregue el nombre del encabezado de autorización. En **Nombre**, escriba el nombre de encabezado que coincida con el nombre de **Origen del token** que especificó al crear el autorizador de Lambda para la API. Este paso no se aplica a los autorizadores `REQUEST`. 1. Seleccione **Save**. 1. Elija **Deploy API (Implementar API)** para implementar la API en una etapa. Para un autorizador `REQUEST` que utiliza variables de etapa, también debe definir las variables de etapa necesarias y especificar los valores en la página **Etapas**. ## Configuración de un método para utilizar un autorizador de Lambda (AWS CLI) Después de configurar el autorizador de Lambda, debe asociarlo a un método para la API. Puede crear un método nuevo o utilizar una operación de parche para asociar un autorizador a un método existente. Si el autorizador utiliza el almacenamiento en caché de la autorización, asegúrese de actualizar la política para controlar el acceso del método adicional. El siguiente comando [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) permite crear un método nuevo que utilice un autorizador de Lambda: ``` aws apigateway put-method --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --authorization-type CUSTOM \ --authorizer-id efg1234 ``` El siguiente comando [update-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-method.html) permite actualizar un método existente para que utilice un autorizador de 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" ``` # Entrada de un autorizador de Lambda de API Gateway En la siguiente sección se explica el formato de la entrada de API Gateway para un autorizador de Lambda. ## Formato de entrada de `TOKEN` Para un autorizador de Lambda (que anteriormente se denominaba autorizador personalizado) del tipo `TOKEN`, debe especificar un encabezado personalizado como **Token Source (Origen del token)** al configurar el autorizador para una API. El cliente de la API debe transmitir el token de autorización necesario en ese encabezamiento en la solicitud de entrada. Tras recibir la solicitud del método de entrada, API Gateway extrae el token del encabezado personalizado. A continuación, transmite el token como propiedad `authorizationToken` del objeto `event` de la función de Lambda, además del ARN del método como propiedad `methodArn`: ``` { "type":"TOKEN", "authorizationToken":"{caller-supplied-token}",     "methodArn":"arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ``` En este ejemplo, la propiedad `type` especifica el tipo de autorizador, que es un autorizador `TOKEN`. `{caller-supplied-token}` procede del encabezado de autorización de una solicitud del cliente y puede ser cualquier valor de cadena. `methodArn` es el ARN de la solicitud del método de entrada y lo rellena API Gateway de acuerdo con la configuración del autorizador de Lambda. ## Formato de entrada de `REQUEST` Para un autorizador de Lambda del tipo `REQUEST`, API Gateway transmite los parámetros de solicitud a la función de Lambda del autorizador como parte del objeto `event`. Los parámetros de solicitud incluyen encabezados, parámetros de ruta, parámetros de cadenas de consulta, variables de etapa y algunas variables de contexto de solicitud. El intermediario de la API puede definir parámetros de ruta, encabezados y parámetros de cadenas de consulta. El desarrollador de la API debe establecer las variables de etapa durante la implementación de la API y API Gateway proporciona el contexto de la solicitud en tiempo de ejecución. **nota** Los parámetros de la ruta se pueden pasar como parámetros de solicitud a la función del autorizador de Lambda pero no se pueden usar como fuentes de identidad. El siguiente ejemplo muestra una entrada de un autorizador `REQUEST` para un método de la API (`GET /request`) con una integración de 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" } } ``` `requestContext` es un mapa de pares de clave-valor y se corresponde con la variable [\$1context](api-gateway-mapping-template-reference.md#context-variable-reference). Su resultado depende de la API. API Gateway podría agregar nuevas claves al mapa. Para obtener más información sobre la entrada de la función de Lambda en una integración de proxy, consulte [Formato de entrada de una función de Lambda para la integración de proxy](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-input-format). # Salida de un autorizador de Lambda de API Gateway La salida de una función de autorizador de Lambda es un objeto similar a un diccionario que debe incluir el identificador de la entidad principal (`principalId`) y un documento de política (`policyDocument`) que contenga una lista de instrucciones de política. La salida también puede incluir un mapa `context` que contenga pares de clave-valor. Si la API utiliza un plan de uso ([https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource) se ha establecido en `AUTHORIZER`), la función de autorizador de Lambda debe devolver una de las claves de API del plan de uso como valor de la propiedad `usageIdentifierKey`. A continuación se muestra un ejemplo de esta salida. ------ #### [ 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}" } ``` ------ Aquí, una instrucción de política especifica si se permite o deniega (`Effect`) al servicio de ejecución de API Gateway invocar (`Action`) el método de API especificado (`Resource`). Es posible que tenga que controlar el acceso a varios recursos en función del autorizador. Puede utilizar un carácter comodín (`*`) para especificar un tipo de recurso (método). Para obtener información sobre la configuración de políticas válidas para llamar a una API, consulte [Referencia de instrucciones de políticas de IAM para ejecutar la API en API Gateway](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-calling-api-permissions). En el caso de los ARN del método con autorización habilitada (por ejemplo, `arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]`), la longitud máxima es de 1600 bytes. Los valores de parámetros de ruta, cuyo tamaño se determina en tiempo de ejecución, pueden provocar que la longitud del ARN supere el límite. Cuando esto ocurra, el cliente de la API recibirá una respuesta `414 Request URI too long`. Además, el ARN de recurso, tal y como se muestra en la instrucción de política de salida que ha realizado el autorizador, está limitado actualmente a 512 caracteres. Por este motivo, no debe utilizar la URI con un token JWT que tenga una longitud considerable en una URI de la solicitud. Puede transferir de manera segura el token JWT en un encabezado de solicitud. Puede tener acceso al valor `principalId` de una plantilla de asignación utilizando la variable `$context.authorizer.principalId`. Esto resulta útil si desea transmitir el valor al backend. Para obtener más información, consulte [Variables de contexto para transformaciones de datos](api-gateway-mapping-template-reference.md#context-variable-reference). Puede obtener acceso al valor de `stringKey`, `numberKey` o `booleanKey` (por ejemplo, `"value"`, `"1"` o `"true"`) del mapa `context` en una plantilla de mapeo llamando a `$context.authorizer.stringKey`, `$context.authorizer.numberKey` o `$context.authorizer.booleanKey`, respectivamente. Los valores devueltos se representan en forma de cadena. Observe que no puede establecer un objeto o matriz JSON como un valor válido de ninguna clave en el mapa `context`. Puede utilizar el mapa `context` para devolver las credenciales almacenadas en caché del autorizador al backend utilizando una plantilla de mapeo de una solicitud de integración. Esto permite que el backend proporcione una mejor experiencia de usuario mediante la utilización de las credenciales almacenadas en caché para reducir la necesidad de obtener acceso a las claves secretas y abrir los tokens de autorización para cada solicitud. En el caso de la integración de proxy de Lambda, API Gateway transmite el objeto `context` de un autorizador de Lambda directamente a la función de Lambda del backend como parte de la entrada `event`. Puede recuperar los pares de clave-valor de `context` en la función de Lambda llamando a `$event.requestContext.authorizer.key`. `{api-key}` representa una clave de API en el plan de uso de la etapa de API. Para obtener más información, consulte [Planes de uso y clave de API para las API de REST en API Gateway](api-gateway-api-usage-plans.md). El siguiente ejemplo muestra la salida del ejemplo de autorizador de Lambda. El resultado de ejemplo contiene una instrucción de política para bloquear (`Deny`) las llamadas al método `GET` para la etapa `dev` de una API (`ymy8tbxw7b`) de una cuenta de AWS (`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/" } ] } } ``` ------ # Llamada a una API con un autorizador de Lambda de API Gateway Después de configurar el autorizador de Lambda (que anteriormente se denominaba autorizador personalizado); e implementar la API, debe probar la API con el autorizador de Lambda habilitado. Para ello, necesita un cliente REST, como cURL o [Postman](https://www.postman.com/). En los siguientes ejemplos, usamos Postman. **nota** Al llamar a un método habilitado para un autorizador, API Gateway no registra la llamada a CloudWatch si el token necesario para el autorizador `TOKEN` no se establece, es nulo o no es válido para la expresión **Token validation expression (Expresión de validación de token)** especificada. Del mismo modo, API Gateway no registra la llamada a CloudWatch si alguno de los orígenes de identidad necesarios para el autorizador `REQUEST` no está establecido, es nulo o está vacío. A continuación, mostramos cómo utilizar Postman para llamar a la API o probarla con un autorizador de Lambda `TOKEN`. El método puede usarse para llamar a una API con un autorizador de Lambda `REQUEST` si se especifican los parámetros de ruta, encabezado o cadena de consulta necesarios de forma explícita. **Llamar a una API con el autorizador personalizado `TOKEN`** 1. Abra **Postman**, elija el método **GET** y pegue el valor de **Invoke URL (Invocar URL)** de la API en el campo URL contiguo. Agregue el encabezado de token de autorización de Lambda y establezca el valor en `allow`. Seleccione **Send (enviar)**. ![\[Cómo llamar a la API con el token Allow de autorización de Lambda\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/custom-auth-call-api-with-allow-token.png) La respuesta muestra que el autorizador de Lambda de API Gateway devuelve una respuesta **200 OK** y autoriza correctamente a la llamada para que tenga acceso al punto de conexión HTTP (http://httpbin.org/get) integrado en el método. 1. Sin salir de Postman, cambie el valor del encabezado de token de autorización de Lambda a `deny`. Seleccione **Send (enviar)**. ![\[Cómo llamar a la API con el token Deny de autorización de Lambda\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/custom-auth-call-api-with-deny-token.png) La respuesta muestra que el autorizador de Lambda de API Gateway devuelve una respuesta **403 Forbidden** que no autoriza a la llamada para que tenga acceso al punto de conexión HTTP. 1. En Postman, cambie el valor del encabezado de token de autorización de Lambda a `unauthorized` y elija **Send (Enviar)**. ![\[Cómo llamar a la API con un token Unauthorized de autorización de Lambda\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/custom-auth-call-api-with-unauthorized-token.png) La respuesta muestra que API Gateway devuelve una respuesta **401 Unauthorized** sin autorizar la llamada para tener acceso al punto de conexión HTTP. 1. Ahora, cambie el valor del encabezado de token de autorización de Lambda a `fail`. Seleccione **Send (enviar)**. ![\[Cómo llamar a la API con el token Fail de autorización de Lambda\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/custom-auth-call-api-with-fail-token.png) La respuesta muestra que API Gateway devuelve una respuesta **500 Internal Server Error** sin autorizar la llamada para tener acceso al punto de conexión HTTP. # Configuración de un autorizador de Lambda de API Gateway entre cuentas Ahora también se puede utilizar una función de AWS Lambda de otra cuenta de AWS como función de autorizador de API. Cada cuenta puede estar en cualquier región en la que Amazon API Gateway esté disponible. La función de autorizador de Lambda puede utilizar estrategias de autenticación de token al portador como OAuth o SAML. Esto permite administrar y compartir fácilmente de forma centralizada la función de autorizador de Lambda en distintas API de API Gateway. En esta sección, mostramos cómo configurar una función de autorización de Lambda entre cuentas mediante la consola de Amazon API Gateway. En estas instrucciones, se presupone que usted ya dispone de una API de API Gateway en una cuenta de AWS y de una función de autorizador de Lambda en otra cuenta. ## Configurar un autorizador de Lambda entre cuentas mediante la consola de API Gateway Inicie sesión en la consola de Amazon API Gateway en la cuenta que tiene la API y, a continuación, haga lo siguiente: 1. Elija la API y, a continuación, en el panel de navegación principal, elija **Autorizadores**. 1. Elija **Crear autorizador**. 1. En **Nombre del autorizador**, ingrese un nombre para el autorizador. 1. En **Tipo de autorizador**, seleccione **Lambda**. 1. En **Función de Lambda**, copie y pegue el ARN completo de la función del autorizador de Lambda que tiene en la segunda cuenta. **nota** En la consola de Lambda, puede encontrar el ARN de la función en la esquina superior derecha de la ventana de la consola. 1. Aparecerá una advertencia con una cadena de comandos `aws lambda add-permission`. La política concede permiso de API Gateway para invocar la función de Lambda del autorizador. Copie el comando y guárdelo para más adelante. Ejecute el comando después de crear el autorizador. 1. En **Carga útil del evento de Lambda**, seleccione **Token** para un autorizador `TOKEN` o **Solicitud** para un autorizador `REQUEST`. 1. Dependiendo de la elección del paso anterior, lleve a cabo alguna de las siguientes operaciones: 1. Para la opción **Token**, haga lo siguiente: + En **Origen del token**, ingrese el nombre del encabezado que contiene el token de autorización. El cliente de la API debe incluir un encabezado con este nombre para enviar el token de autorización al autorizador de Lambda. + Si lo desea, en **Validación del token**, ingrese una instrucción RegEx. API Gateway realiza la validación inicial del token de entrada contra esta expresión e invoca el autorizador tras una validación correcta. Esto ayuda a reducir las llamadas a la API. + Para almacenar en caché la política de autorización generada por el autorizador, mantenga activado **Almacenamiento en caché de la autorización**. Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor **TTL**. Si establece **TTL** en cero se desactivará el almacenamiento en caché de políticas. Cuando el almacenamiento en caché de las políticas esté habilitado, el nombre del encabezado especificado en **Origen del token** pasará a ser la clave de caché. Si se pasan varios valores a este encabezado de la solicitud, todos los valores se convertirán en la clave de caché y se conservará el orden. **nota** El valor de **TTL** predeterminado es de 300 segundos. El valor máximo es de 3600 segundos, este límite no se puede aumentar. 1. Para la opción **Request (Solicitud)**, haga lo siguiente: + En **Tipo de origen de identidades**, seleccione un tipo de parámetro. Los tipos de parámetro admitidos son `Header`, `Query string`, `Stage variable` y `Context`. Para agregar más orígenes de identidades, elija **Agregar parámetro**. + Para almacenar en caché la política de autorización generada por el autorizador, mantenga activado **Almacenamiento en caché de la autorización**. Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor **TTL**. Si establece **TTL** en cero se desactivará el almacenamiento en caché de políticas. API Gateway utiliza las fuentes de identidad especificadas como la clave de caché del autorizador de la solicitud. Cuando está habilitado el almacenamiento en caché, API Gateway llama a la función de Lambda del autorizador solo después de verificar correctamente que todas las fuentes de identidad especificadas estén presentes en tiempo de ejecución. Si falta un origen de identidad especificado, es nulo o está vacío, API Gateway devuelve una respuesta `401 Unauthorized` sin llamar a la función de Lambda del autorizador. Cuando se definen varias fuentes de identidad, se utilizan todas ellas para obtener la clave de caché del autorizador. Cambiar cualquiera de las partes de la clave de caché hace que el autorizador descarte el documento de políticas almacenado en caché y genere otro nuevo. Si se pasa un encabezado con varios valores en la solicitud, todos los valores se convertirán en la clave de caché y se conservará el orden. + ‎Cuando está desactivado el almacenamiento en caché, no es necesario especificar ningún origen de identidades. **nota** Para habilitar el almacenamiento en caché, su autorizador debe devolver una política que se aplique a todos los métodos a través de una API. Para aplicar una política específica de método, puede desactivar **Almacenamiento en caché de la autorización**. 1. Elija **Crear autorizador**. 1. Pegue la cadena de comandos `aws lambda add-permission` que copió durante un paso anterior en una ventana de la AWS CLI, que está configurada para la segunda cuenta. Reemplace `AUTHORIZER_ID` por el ID de su autorizador. Este concederá a la primera cuenta acceso a la función de autorizador de Lambda de la segunda cuenta. # Control del acceso en función de los atributos de una identidad con Verified Permissions Utilice Amazon Verified Permissions para controlar el acceso a su API de API Gateway. Cuando utiliza API Gateway con Verified Permissions, Verified Permissions crea un autorizador de Lambda que utiliza decisiones de autorización detalladas para controlar el acceso a la API. Verified Permissions autoriza a los intermediarios según el esquema y las políticas del almacenamiento de políticas mediante el lenguaje de políticas de Cedar para definir permisos detallados para los usuarios de las aplicaciones. Para obtener más información, consulte [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) en la *Guía del usuario de Amazon Verified Permissions*. Verified Permissions admite grupos de usuarios de Amazon Cognito o proveedores de identidad OpenID Connect (OIDC) como orígenes de identidad. Verified Permissions presupone que la entidad principal se ha identificado y autenticado previamente. Verified Permissions solo es compatible con las API de REST regionales y optimizadas para la periferia. ## Creación de un autorizador de Lambda mediante Verified Permissions Verified Permissions crea un autorizador de Lambda para determinar si una entidad principal está autorizada a realizar una acción en la API. Cree la política de Cedar que Verified Permissions utiliza para realizar sus tareas de autorización. En el siguiente ejemplo se muestra una política de Cedar que permite el acceso para invocar una API basada en el grupo de usuarios de Amazon Cognito, `us-east-1_ABC1234` para el grupo `developer` en el recurso `GET /users` de una API. Verified Permissions determina la pertenencia al grupo mediante el análisis del token portador para la identidad del intermediario. ``` permit( principal in MyAPI::UserGroup::"us-east-1_ABC1234|developer", action in [ MyAPI::Action::"get /users" ], resource ); ``` De forma opcional, Verified Permissions puede asociar el autorizador a los métodos de la API. En las etapas de producción de la API, le recomendamos que no permita que Verified Permissions asocie el autorizador por usted. En la siguiente lista se muestra cómo configurar Verified Permissions para asociar o no el autorizador de Lambda a la solicitud de los métodos de la API. **Asociación del autorizador por usted (Consola de administración de AWS)** Cuando elija **Crear almacén de políticas** en la consola de Verified Permissions, en la página **Implementar integración de aplicaciones**, elija **Ahora**. **Sin asociación del autorizador por usted (Consola de administración de AWS)** Cuando elija **Crear almacén de políticas** en la consola de Verified Permissions, en la página **Implementar integración de aplicaciones**, elija **Más tarde**. Verified Permissions sigue creando un autorizador de Lambda por usted. El autorizador de Lambda comienza por `AVPAuthorizerLambda-`. Para obtener más instrucciones sobre cómo adjuntar el autorizador en un método, consulte [Configuración de un método para utilizar un autorizador de Lambda (consola)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-console). **Asociación del autorizador por usted (CloudFormation)** En la plantilla CloudFormation generada por Verified Permissions, en la sección `Conditions`, establezca `"Ref": "shouldAttachAuthorizer"` a `true`. **Sin asociación del autorizador por usted (CloudFormation)** En la plantilla CloudFormation generada por Verified Permissions, en la sección `Conditions`, establezca `"Ref": "shouldAttachAuthorizer"` a `false`. Verified Permissions sigue creando un autorizador de Lambda por usted. El autorizador de Lambda comienza por `AVPAuthorizerLambda-`. Para obtener más instrucciones sobre cómo adjuntar el autorizador en un método, consulte [Configuración de un método para utilizar un autorizador de Lambda (AWS CLI)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-cli). ## Llamada a un autorizador de Lambda mediante Verified Permissions Puede llamar a al autorizador de Lambda si proporciona una identidad o un token de acceso en el encabezado `Authorization`. Para obtener más información, consulte [Llamada a una API con un autorizador de Lambda de API Gateway](call-api-with-api-gateway-lambda-authorization.md). API Gateway almacena en caché la política que devuelve el autorizador de Lambda durante 120 segundos. Puede modificar el TTL en la consola de API Gateway o mediante la AWS CLI.