Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Uso di autorizzazioni Lambda di API Gateway Usa un *sistema di autorizzazione Lambda* (noto in precedenza come *sistema di autorizzazione ad hoc*) per controllare l'accesso all'API. Quando un client effettua una richiesta al metodo dell’API, Gateway API chiama il sistema di autorizzazione Lambda. Il sistema di autorizzazione Lambda accetta l'identità del chiamante come input e restituisce una policy IAM come output. Usa un sistema di autorizzazione Lambda per implementare uno schema di autorizzazione personalizzato. Il tuo schema può utilizzare i parametri di richiesta per determinare l'identità del chiamante o utilizzare una strategia di autenticazione con token portatore come OAuth o SAML. Crea un autorizzatore Lambda nella console API REST di API Gateway, utilizzando o un AWS CLI SDK. AWS ## Flusso di lavoro di autorizzazione per il sistema di autorizzazione Lambda Il diagramma seguente mostra il flusso di lavoro di autorizzazione per un sistema di autorizzazione Lambda. ![\[Flusso di lavoro per le autorizzazioni Lambda di API Gateway\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/custom-auth-workflow.png) **Flusso di lavoro per le autorizzazioni Lambda di API Gateway** 1. Il client chiama un metodo in un'API di Gateway API, passando un token di connessione o i parametri della richiesta. 1. Gateway API verifica se la richiesta di metodo è configurata con un sistema di autorizzazione Lambda. In tal caso, API Gateway chiama la funzione Lambda. 1. La funzione Lambda autentica il chiamante. La funzione può eseguire l'autenticazione nei modi seguenti: + Chiamando un OAuth provider per ottenere un OAuth token di accesso. + Chiamando un provider SAML per ottenere un'asserzione SAML. + Generando una policy IAM in base ai valori dei parametri della richiesta. + Recuperando le credenziali da un database. 1. La funzione Lambda restituisce una policy IAM e un identificatore principale. Se la funzione Lambda non restituisce tali informazioni, la chiamata ha esito negativo. 1. Gateway API valuta la policy IAM. + Se l'accesso viene negato, Gateway API restituisce un codice di stato HTTP appropriato, ad esempio `403 ACCESS_DENIED`. + Se l'accesso viene concesso, Gateway API invoca il metodo. Se si abilita il caching delle autorizzazioni, Gateway API memorizza la policy nella cache in modo che non venga invocata nuovamente la funzione del sistema di autorizzazione Lambda. È necessario assicurarsi che la policy sia applicabile a tutte le risorse e ai metodi dell’API. È possibile personalizzare le risposte `403 ACCESS_DENIED` o `401 UNAUTHORIZED` del gateway. Per ulteriori informazioni, consulta [Risposte gateway per REST APIs in API Gateway](api-gateway-gatewayResponse-definition.md). ## Scelta di un tipo di sistema di autorizzazione Lambda Esistono due tipi di autorizzazioni Lambda: **Sistema di autorizzazione Lambda basato sui parametri della richiesta (sistema di autorizzazione `REQUEST`)** Un sistema di autorizzazione `REQUEST` riceve l'identità del chiamante in una combinazione di intestazioni, parametri della stringa di query, [`stageVariables`](api-gateway-mapping-template-reference.md#stagevariables-template-reference) e variabili [`$context`](api-gateway-mapping-template-reference.md#context-variable-reference). È possibile utilizzare un sistema di autorizzazione `REQUEST` per creare policy dettagliate in base a informazioni provenienti da più origini di identità, ad esempio le variabili di contesto `$context.path` e `$context.httpMethod`. Se attivi il caching delle autorizzazioni per un sistema di autorizzazione `REQUEST`, Gateway API verifica che nella richiesta siano presenti tutte le origini di identità specificate. Se un'origine di identità specificata non è presente, è null o è vuota, Gateway API restituisce una risposta HTTP `401 Unauthorized` senza chiamare la funzione del sistema di autorizzazione Lambda. Quando sono definite più origini di identità, vengono utilizzate tutte per derivare la chiave cache del sistema di autorizzazione, mantenendo l'ordine. È possibile definire una chiave di cache dettagliata utilizzando più origini di identità. Se modifichi qualsiasi parte della chiave di cache, il sistema di autorizzazione rimuove il documento di policy memorizzato nella cache e ne generano uno nuovo. Se disattivi il caching delle autorizzazioni per un sistema di autorizzazione `REQUEST`, Gateway API passa direttamente la richiesta alla funzione Lambda. **Sistema di autorizzazione Lambda basato su token (sistema di autorizzazione `TOKEN`)** Un `TOKEN` autorizzatore riceve l'identità del chiamante in un token portante, ad esempio un JSON Web Token (JWT) o un token. OAuth Se attivi il caching delle autorizzazioni per un sistema di autorizzazione `TOKEN`, il nome dell'intestazione specificato nell'origine token diventa la chiave di cache. Inoltre, puoi utilizzare la convalida dei token per inserire una dichiarazione. RegEx Gateway API esegue la convalida iniziale del token di input per l'espressione e, se la convalida ha esito positivo, invoca la funzione del sistema di autorizzazione Lambda. Ciò aiuta a ridurre le chiamate all'API. La proprietà `IdentityValidationExpression` è supportata solo per i sistemi di autorizzazione `TOKEN`. Per ulteriori informazioni, consulta [x-amazon-apigateway-authorizer oggetto](api-gateway-swagger-extensions-authorizer.md). **Nota** È consigliabile utilizzare un sistema di autorizzazione `REQUEST` per controllare l'accesso all'API. Puoi controllare l'accesso all'API in base a più origini di identità quando usi un sistema di autorizzazione `REQUEST` e in base a una singola origine di identità quando usi un sistema di autorizzazione `TOKEN`. Inoltre, puoi separare le chiavi di cache utilizzando più origini di identità per un sistema di autorizzazione `REQUEST`. ## Esempio di funzione del sistema di autorizzazione `REQUEST` Lambda Il codice di esempio seguente crea una funzione del sistema di autorizzazione Lambda che consente una richiesta se l'intestazione `HeaderAuth1` fornita dal client, il parametro di query `QueryString1` e la variabile di fase di `StageVar1` corrispondono, rispettivamente, ai valori specificati di `headerValue1`, `queryValue1` e `stageValue1`. ------ #### [ 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) ``` ------ In questo esempio, la funzione di autorizzazione Lambda controlla i parametri di input e si comporta nel modo seguente: + Se tutti i valori dei parametri richiesti corrispondono ai valori previsti, la funzione di autorizzazione restituisce una risposta HTTP `200 OK` e una policy IAM simile alla seguente e la richiesta del metodo ha esito positivo: ------ #### [ 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/" } ] } ``` ------ + In caso contrario, la funzione del sistema di autorizzazione restituisce una risposta HTTP `401 Unauthorized` e la richiesta di metodo ha esito negativo. Oltre a restituire una policy IAM, la funzione di autorizzazione Lambda deve restituire anche l'identificatore dell'entità principale dell'intermediario. Facoltativamente, può restituire un oggetto `context` contenente informazioni aggiuntive che possono essere passate al backend di integrazione. Per ulteriori informazioni, consulta [Output da un sistema di autorizzazione Lambda di Gateway API](api-gateway-lambda-authorizer-output.md). Nel codice di produzione può essere necessario autenticare l'utente prima di concedere l'autorizzazione. Puoi aggiungere una logica di autenticazione nella funzione Lambda chiamando un provider di autenticazione come indicato nella documentazione del provider. ## Esempio di funzione del sistema di autorizzazione `TOKEN` Lambda Il codice di esempio seguente crea una funzione di autorizzazione `TOKEN` Lambda che consente a un chiamante di invocare un metodo se il valore del token fornito dal client è `allow`. Al chiamante non è consentito invocare la richiesta se il valore del token è `deny`. Se il valore del token è `unauthorized` o una stringa vuota, la funzione del sistema di autorizzazione restituisce una risposta `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 ``` ------ In questo esempio, quando l'API riceve una richiesta del metodo, API Gateway passa il token di origine alla funzione di autorizzazione Lambda nell'attributo `event.authorizationToken`. La funzione di autorizzazione Lambda legge il token e si comporta nel modo seguente: + Se il valore del token è `allow`, la funzione di autorizzazione restituisce una risposta HTTP `200 OK` e una policy IAM simile alla seguente e la richiesta del metodo ha esito positivo: ------ #### [ 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/" } ] } ``` ------ + Se il valore del token è `deny`, la funzione di autorizzazione restituisce una risposta HTTP `200 OK` e una policy IAM `Deny` simile alla seguente e la richiesta del metodo ha esito negativo: ------ #### [ 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** Esternamente all'ambiente di test, Gateway API restituisce una risposta HTTP `403 Forbidden` e la richiesta di metodo ha esito negativo. + Se il valore del token è `unauthorized` o una stringa vuota, la funzione del provider di autorizzazione restituisce una risposta HTTP `401 Unauthorized` e la chiamata al metodo ha esito negativo. + Se il token ha un valore diverso dai precedenti, il client riceve una risposta `500 Invalid token` e la chiamata al metodo ha esito negativo. Oltre a restituire una policy IAM, la funzione di autorizzazione Lambda deve restituire anche l'identificatore dell'entità principale dell'intermediario. Facoltativamente, può restituire un oggetto `context` contenente informazioni aggiuntive che possono essere passate al backend di integrazione. Per ulteriori informazioni, consulta [Output da un sistema di autorizzazione Lambda di Gateway API](api-gateway-lambda-authorizer-output.md). Nel codice di produzione può essere necessario autenticare l'utente prima di concedere l'autorizzazione. Puoi aggiungere una logica di autenticazione nella funzione Lambda chiamando un provider di autenticazione come indicato nella documentazione del provider. ## Esempi aggiuntivi di funzioni del sistema di autorizzazione Lambda L'elenco seguente mostra altri esempi di funzioni del sistema di autorizzazione Lambda. Puoi creare una funzione Lambda nello stesso account o in un account diverso da quello da cui hai creato l'API. Per l'esempio precedente di funzioni Lambda, puoi utilizzare le funzioni integrate [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html), poiché queste funzioni non chiamano altri AWS servizi. Se la tua funzione Lambda chiama altri AWS servizi, dovrai assegnare un ruolo di esecuzione IAM alla funzione Lambda. Per creare il ruolo, segui le istruzioni in [AWS Lambda Ruolo di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html). **Esempi aggiuntivi di funzioni del sistema di autorizzazione Lambda** + Per un esempio di applicazione, vedere [Open Banking Brasile - Esempi di autorizzazione](https://github.com/aws-samples/openbanking-brazilian-auth-samples) GitHub su. + Per altri esempi di funzioni Lambda, vedi [ aws-apigateway-lambda-authorizer-blueprints](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints) on. GitHub + Puoi creare un sistema di autorizzazione Lambda che autentica gli utenti utilizzando i pool di utenti di Amazon Cognito e autorizza i chiamanti in base a un archivio di policy utilizzando Autorizzazioni verificate. Per ulteriori informazioni, consulta [Controllo dell'accesso in base agli attributi di un'identità con Autorizzazioni verificate](apigateway-lambda-authorizer-verified-permissions.md). + La console Lambda fornisce un blueprint Python, che puoi usare scegliendo **Usa un blueprint e scegliendo il blueprint**. **api-gateway-authorizer-python** # Configurazione di un sistema di autorizzazione Lambda di Gateway API Dopo aver creato una funzione Lambda, configuri la funzione Lambda come sistema di autorizzazione per la tua API. Quindi configuri il metodo per invocare il sistema di autorizzazione Lambda per stabilire se un chiamante può invocare il tuo metodo. Puoi creare una funzione Lambda nello stesso account o in un account diverso da quello da cui hai creato l'API. Puoi testare il sistema di autorizzazione Lambda utilizzando gli strumenti integrati nella console Gateway API o utilizzando [Postman](https://www.postman.com/). Per istruzioni su come utilizzare Postman per testare la funzione del sistema di autorizzazione Lambda, consulta [Chiamata di un'API con il sistema di autorizzazione Lambda di Gateway API](call-api-with-api-gateway-lambda-authorization.md). ## Configurazione di un sistema di autorizzazione Lambda (console) La procedura seguente illustra come creare un sistema di autorizzazione Lambda nella console REST API di Gateway API. Per ulteriori informazioni sui diversi tipi di sistemi di autorizzazione Lambda, consulta [Scelta di un tipo di sistema di autorizzazione Lambda](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-choose). ------ #### [ REQUEST authorizer ] **Configurazione di un sistema di autorizzazione Lambda `REQUEST`** 1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Seleziona un'API, quindi scegli **Autorizzazioni**. 1. Scegli **Crea autorizzazioni**. 1. In **Nome del provider di autorizzazioni**, immetti il nome di un provider di autorizzazioni. 1. In **Tipo di autorizzazione**, seleziona **Lambda**. 1. Per la **funzione Lambda**, seleziona il Regione AWS luogo in cui hai creato la funzione di autorizzazione Lambda, quindi inserisci il nome della funzione. 1. Non specificare nulla in **Ruolo di richiamo Lambda** per consentire alla console REST API di Gateway API di impostare una policy basata sulle risorse. La policy concede a Gateway API le autorizzazioni per invocare la funzione del sistema di autorizzazione Lambda. Puoi anche scegliere di immettere il nome di un ruolo IAM per consentire a Gateway API di invocare la funzione del sistema di autorizzazione Lambda. Per un ruolo di esempio, consulta [Creazione di un ruolo IAM prevedibile](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. In **Payload evento Lambda**, scegli **Richiesta**. 1. In **Tipo di origine identità**, seleziona un tipo di parametro. I tipi di parametri supportati sono `Header`, `Query string`, `Stage variable` e `Context`. Per aggiungere altre origini di identità, scegli **Aggiungi parametro**. 1. Per memorizzare nella cache la policy di autorizzazione generata dalla funzione di autorizzazione, attiva l'opzione **Autorizzazione caching**. Quando il caching delle policy è abilitato, puoi modificare il valore **TTL**. L'impostazione dell'opzione **TTL** su zero disabilita la memorizzazione nella cache delle policy. Per abilitare il caching, il sistema di autorizzazione deve restituire una policy applicabile a tutti i metodi di un'API. Per applicare una policy specifica del metodo, utilizza le variabili di contesto `$context.path` e `$context.httpMethod`. 1. Scegli **Crea autorizzazioni**. ------ #### [ TOKEN authorizer ] **Configurazione di un sistema di autorizzazione Lambda `TOKEN`** 1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Seleziona un'API, quindi scegli **Autorizzazioni**. 1. Scegli **Crea autorizzazioni**. 1. In **Nome del provider di autorizzazioni**, immetti il nome di un provider di autorizzazioni. 1. In **Tipo di autorizzazione**, seleziona **Lambda**. 1. Per la **funzione Lambda**, seleziona il Regione AWS luogo in cui hai creato la funzione di autorizzazione Lambda, quindi inserisci il nome della funzione. 1. Non specificare nulla in **Ruolo di richiamo Lambda** per consentire alla console REST API di Gateway API di impostare una policy basata sulle risorse. La policy concede a Gateway API le autorizzazioni per invocare la funzione del sistema di autorizzazione Lambda. Puoi anche scegliere di immettere il nome di un ruolo IAM per consentire a Gateway API di invocare la funzione del sistema di autorizzazione Lambda. Per un ruolo di esempio, consulta [Creazione di un ruolo IAM prevedibile](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies). 1. In **Payload evento Lambda**, scegli **Token**. 1. In **Origine token**, immetti il nome dell'intestazione contenente il token di autorizzazione. Il client API deve includere un'intestazione con questo nome per inviare il token di autorizzazione al sistema di autorizzazione Lambda. 1. (Facoltativo) Per la **convalida del token**, inserisci una dichiarazione. RegEx API Gateway esegue la convalida iniziale del token di input per l'espressione e, se la convalida ha esito positivo, richiama l'autorizzazione. 1. Per memorizzare nella cache la policy di autorizzazione generata dalla funzione di autorizzazione, attiva l'opzione **Autorizzazione caching**. Quando la memorizzazione della policy nella cache è abilitata, il nome dell'intestazione specificato in **Origine token** diventa la chiave della cache. Quando il caching delle policy è abilitato, puoi modificare il valore **TTL**. L'impostazione dell'opzione **TTL** su zero disabilita la memorizzazione nella cache delle policy. Per abilitare il caching, il sistema di autorizzazione deve restituire una policy applicabile a tutti i metodi di un'API. Per applicare policy specifiche del metodo, puoi disattivare l'opzione **Memorizzazione nella cache dell'autorizzazione**. 1. Scegli **Crea autorizzazioni**. ------ Dopo aver creato il sistema di autorizzazione Lambda, puoi testarlo. La procedura seguente illustra come testare il sistema di autorizzazione Lambda. ------ #### [ REQUEST authorizer ] **Per testare un sistema di autorizzazione Lambda `REQUEST`** 1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Seleziona il nome del sistema di autorizzazione. 1. In **Testa autorizzazioni**, inserisci un valore per la tua origine di identità. Se utilizzi [Esempio di funzione del sistema di autorizzazione `REQUEST` Lambda](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-request-lambda-function-create), procedi nel modo seguente: 1. Seleziona **Intestazione** e immetti **headerValue1**, quindi scegli **Aggiungi parametro**. 1. In **Tipo di origine identità**, seleziona **Stringa di query** e immetti **queryValue1**, quindi scegli **Aggiungi parametro**. 1. In **Tipo di origine identità**, seleziona **Variabile di fase** e immetti **stageValue1**. Non puoi modificare le variabili di contesto per l'invocazione di test, ma puoi modificare il modello di evento di test **Sistema di autorizzazione di Gateway API** per la tua funzione Lambda. Quindi, puoi testare la funzione del sistema di autorizzazione Lambda con variabili di contesto modificate. Per ulteriori informazioni, consulta [Testing Lambda functions in the console](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html) nella *Guida per gli sviluppatori di AWS Lambda *. 1. Scegli **Testa autorizzazioni**. ------ #### [ TOKEN authorizer ] **Per testare un sistema di autorizzazione Lambda `TOKEN`** 1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Seleziona il nome del sistema di autorizzazione. 1. In **Testa autorizzazioni**, inserisci un valore per il token. Se utilizzi [Esempio di funzione del sistema di autorizzazione `TOKEN` Lambda](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-token-lambda-function-create), procedi nel modo seguente: 1. Per **authorizationToken**, inserisci **allow**. 1. Scegli **Testa autorizzazioni**. Se il sistema di autorizzazione Lambda nega correttamente una richiesta nell'ambiente di test, il test restituisce una risposta HTTP `200 OK`. Esternamente all'ambiente di test, invece, Gateway API restituisce una risposta HTTP `403 Forbidden` e la richiesta di metodo ha esito negativo. ------ ## Configurazione di un sistema di autorizzazione Lambda (AWS CLI) Il seguente comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) mostra come creare un sistema di autorizzazione Lambda tramite AWS CLI. ------ #### [ REQUEST authorizer ] Il comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) seguente crea un sistema di autorizzazione `REQUEST` e utilizza l’intestazione `Authorizer` e la variabile di contesto `accountId` come origini di 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 ] Il comando [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) seguente crea un sistema di autorizzazione `TOKEN` e utilizza l’intestazione `Authorization` come origine di 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 ``` ------ Dopo aver creato il sistema di autorizzazione Lambda, puoi testarlo. Il [test-invoke-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/test-invoke-authorizer.html)comando seguente verifica un autorizzatore Lambda: ``` aws apigateway test-invoke-authorizer --rest-api-id 1234123412 \ --authorizer-id efg1234 \ --headers Authorization='Value' ``` ## Configurazione di un metodo per utilizzare un sistema di autorizzazione Lambda (console) Dopo aver configurato il sistema di autorizzazione Lambda, devi collegarlo a un metodo per l'API. Se il sistema di autorizzazione utilizza il caching delle autorizzazioni, è necessario aggiornare la policy per controllare l’accesso del metodo aggiuntivo. **Configurazione di un metodo API per utilizzare le autorizzazioni Lambda** 1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Seleziona un'API. 1. Seleziona **Risorse**, quindi scegli un nuovo metodo o scegline uno esistente. 1. Nella scheda **Richiesta metodo**, in **Impostazioni richiesta metodo**, scegli **Modifica**. 1. In **Autorizzazioni**, nel menu a discesa, seleziona la funzione di autorizzazione Lambda appena creata. 1. (Facoltativo) Se desideri passare il token di autorizzazione al back-end, scegli **Intestazioni di richiesta HTTP**. Scegli **Aggiungi intestazione**, quindi aggiungi il nome dell'intestazione di autorizzazione. In **Nome** immetti il nome dell'intestazione corrispondente al nome specificato in **Origine token** al momento della creazione della funzione di autorizzazione Lambda per l'API. Questo passaggio non si applica alle autorizzazioni `REQUEST`. 1. Scegli **Save** (Salva). 1. Seleziona **Deploy API (Distribuisci API)** per distribuire l'API in una fase. Per una funzione di autorizzazione basata su `REQUEST` che usa variabili di fase, devi anche definire le variabili di fase richieste e specificare i relativi valori in **Fasi**. ## Configurazione di un metodo per utilizzare un sistema di autorizzazione Lambda (AWS CLI) Dopo aver configurato il sistema di autorizzazione Lambda, devi collegarlo a un metodo per l'API. Puoi creare un nuovo metodo o utilizzare un'operazione di patch per collegare un sistema di autorizzazione a un metodo esistente. Se il sistema di autorizzazione utilizza il caching delle autorizzazioni, è necessario aggiornare la policy per controllare l’accesso del metodo aggiuntivo. Il comando [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) seguente crea un nuovo metodo che utilizza un sistema di autorizzazione Lambda: ``` aws apigateway put-method --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --authorization-type CUSTOM \ --authorizer-id efg1234 ``` Il comando [update-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-method.html) seguente aggiorna un metodo esistente in modo da utilizzare un sistema di autorizzazione 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" ``` # Input per un sistema di autorizzazione Lambda di Gateway API La sezione seguente illustra il formato di input da Gateway API a un sistema di autorizzazione Lambda. ## Formato di input `TOKEN` Per l'autorizzazione Lambda (nota in precedenza come autorizzazione ad hoc) di tipo `TOKEN`, devi specificare un'intestazione personalizzata in **Token Source (Origine token)** al momento della configurazione dell'autorizzazione per l'API. Il client API deve passare il token di autorizzazione richiesto nell'intestazione nella richiesta in ingresso. Quando riceve la richiesta del metodo in entrata, API Gateway estrae il token dall'intestazione personalizzata. Passa quindi il token come proprietà `authorizationToken` dell'oggetto `event` della funzione Lambda, in aggiunta all'ARN del metodo come proprietà `methodArn`: ``` { "type":"TOKEN", "authorizationToken":"{caller-supplied-token}",     "methodArn":"arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ``` In questo esempio la proprietà `type` specifica il tipo di autorizzazioni, ovvero `TOKEN`. L'oggetto `{caller-supplied-token}` deriva dall'intestazione di autorizzazioni in una richiesta client e può essere qualsiasi valore di stringa. `methodArn` è l'ARN della richiesta del metodo in entrata e viene popolato da API Gateway in base alla configurazione dell'autorizzazione Lambda. ## Formato di input `REQUEST` Per un'autorizzazione per Lambda di tipo `REQUEST`, API Gateway passa i parametri della richiesta alla funzione di autorizzazione Lambda come parte dell'oggetto `event`. I parametri della richiesta includono intestazioni, parametri di percorso, parametri della stringa di query, variabili di fase e alcune variabili di contesto della richiesta. L'autore della chiamata API può impostare parametri di percorso, intestazioni e parametri della stringa di query. Lo sviluppatore dell'API deve impostare le variabili di fase durante la distribuzione dell'API e API Gateway fornisce il contesto della richiesta in fase di runtime. **Nota** I parametri di percorso possono essere passati come parametri della richiesta alla funzione di autorizzazione Lambda, ma non possono essere utilizzati come origini di identità. L'esempio seguente mostra un input per le autorizzazioni `REQUEST` per un metodo API (`GET /request`) con integrazione 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` è una mappa di coppie chiave/valore e corrisponde alla variabile [\$1context](api-gateway-mapping-template-reference.md#context-variable-reference). Il suo risultato dipende dall'API. Gateway API potrebbe aggiungere nuove chiavi alla mappa. Per ulteriori informazioni sull'input della funzione Lambda nell'integrazione proxy Lambda, consulta [Formato di input di una funzione Lambda per l'integrazione proxy](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-input-format). # Output da un sistema di autorizzazione Lambda di Gateway API L'output di una funzione di autorizzazione Lambda è un oggetto simile a un dizionario che deve includere l'identificatore dell'entità principale (`principalId`) e un documento di policy (`policyDocument`) contenente un elenco di dichiarazioni di policy. L'output può includere anche una mappa `context` contenente coppie chiave-valore. Se l'API utilizza un piano di utilizzo ([https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource) è impostato su `AUTHORIZER`), la funzione di autorizzazione Lambda deve restituire una delle chiavi API del piano di utilizzo come il valore della proprietà `usageIdentifierKey`. Di seguito è illustrato un esempio di output. ------ #### [ 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}" } ``` ------ In questo caso, una dichiarazione di policy specifica se permettere o rifiutare (`Effect`) al servizio di esecuzione API Gateway di richiamare (`Action`) il metodo API specificato (`Resource`). Potrebbe essere necessario controllare l’accesso a più risorse in base al sistema di autorizzazione. Per specificare un tipo di risorsa (metodo), è possibile usare un carattere jolly (`*`). Per informazioni sull'impostazione di policy valide per chiamare un'API, consulta [Riferimento delle istruzioni delle policy IAM per l'esecuzione dell'API in API Gateway](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-calling-api-permissions). Per un ARN di metodo abilitato per le autorizzazioni, ad esempio `arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]`, la lunghezza massima è 1600 byte. A causa dei valori dei parametri del percorso, la cui dimensione viene determinata al momento dell'esecuzione, l'ARN può superare il limite di lunghezza impostato. In questo caso, il client API riceverà una risposta `414 Request URI too long`. Per l'ARN di risorsa, inoltre, come illustrato nell'output della dichiarazione di policy da parte delle autorizzazioni, è attualmente previsto un limite di 512 caratteri. Per questo motivo, non devi usare un URI con un token JWT di lunghezza significativa in un URI di richiesta. Puoi invece passare senza problemi il token JWT in un'intestazione di richiesta. Puoi accedere al valore di `principalId` in un modello di mappatura usando la variabile `$context.authorizer.principalId`. Ciò è utile se desideri passare il valore al back-end. Per ulteriori informazioni, consulta [Variabili di contesto per le trasformazioni dei dati](api-gateway-mapping-template-reference.md#context-variable-reference). Puoi accedere al valore di `stringKey`, `numberKey` o `booleanKey` (ad esempio `"value"`, `"1"` o `"true"`) della mappa `context` in un modello di mappatura chiamando, rispettivamente, `$context.authorizer.stringKey`, `$context.authorizer.numberKey` o `$context.authorizer.booleanKey`. I valori restituiti sono tutti in formato stringa. Non è possibile impostare una matrice o un oggetto JSON come valore valido di una chiave nella mappa `context`. È possibile usare la mappa `context` per restituire le credenziali memorizzate nella cache dalle autorizzazioni al back-end, usando un modello di mappatura di richiesta di integrazione. In questo modo, il back-end può offrire un'esperienza utente migliore usando le credenziali memorizzate nella cache per ridurre la necessità di accesso alle chiavi segrete e di apertura dei token di autorizzazione per ogni richiesta. Per l'integrazione proxy Lambda, API Gateway passa l'oggetto `context` da un'autorizzazione Lambda direttamente alla funzione Lambda back-end come parte dell'input `event`. È possibile recuperare la coppia chiave/valore `context` nella funzione Lambda chiamando `$event.requestContext.authorizer.key`. `{api-key}` indica una chiave API nel piano di utilizzo della fase API. Per ulteriori informazioni, consulta [Piani di utilizzo e chiavi API per REST APIs in API Gateway](api-gateway-api-usage-plans.md). Di seguito è illustrato l'output dell'autorizzazione Lambda di esempio. L'output di esempio contiene un'istruzione politica per bloccare (`Deny`) le chiamate al `GET` metodo per la `dev` fase di un'API (`ymy8tbxw7b`) di un AWS account (). `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/" } ] } } ``` ------ # Chiamata di un'API con il sistema di autorizzazione Lambda di Gateway API Dopo aver configurato l'autorizzazione Lambda (nota in precedenza come autorizzazione ad hoc) e aver distribuito l'API, devi testare l'API con l'autorizzazione Lambda abilitata. A tale scopo, è necessario un client REST, ad esempio cURL o [Postman](https://www.postman.com/). Per gli esempi seguenti usiamo Postman. **Nota** **Quando si chiama un metodo abilitato all'autorizzazione, API Gateway non registra la chiamata CloudWatch se il token richiesto per l'`TOKEN`autorizzatore non è impostato, è nullo o è invalidato dall'espressione di convalida Token specificata.** Allo stesso modo, API Gateway non registra la chiamata CloudWatch se una delle fonti di identità richieste per l'`REQUEST`autorizzatore non è impostata, è nulla o è vuota. Di seguito viene illustrato come usare Postman per chiamare o testare un'API con l'autorizzazione Lambda `TOKEN`. Il metodo può essere applicato alla chiamata a un'API con l'autorizzazione Lambda `REQUEST` specificando in modo esplicito i parametri di stringa di query, percorso o intestazione richiesti. **Per chiamare un'API con autorizzazioni ad hoc `TOKEN`** 1. Apri **Postman**, scegli il metodo **GET** e incolla il valore di **Invoke URL (URL chiamata)** dell'API nel campo URL adiacente. Aggiungi l'intestazione del token di autorizzazione Lambda e imposta il valore su `allow`. Scegliere **Send (Invia)**. ![\[Chiamata di un'API con il token di autorizzazione Lambda allow\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/custom-auth-call-api-with-allow-token.png) Come illustrato, l'autorizzazione Lambda di API Gateway restituisce una risposta **200 OK** e autorizza la chiamata per l'accesso all'endpoint HTTP (http://httpbin.org/get) integrato con il metodo. 1. Sempre in Postman, modifica il valore dell'intestazione del token di autorizzazione Lambda impostandolo su `deny`. Scegliere **Send (Invia)**. ![\[Chiamata di un'API con il token di autorizzazione Lambda Deny\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/custom-auth-call-api-with-deny-token.png) La risposta mostra che l'autorizzazione Lambda di API Gateway restituisce una risposta **403 Forbidden (403 Non consentito)** senza autorizzare la chiamata per l'accesso all'endpoint HTTP. 1. In Postman, modifica il valore dell'intestazione del token di autorizzazione Lambda impostandolo su `unauthorized` e seleziona **Send (Invia)**. ![\[Chiamata di un'API con il token di autorizzazione Lambda unauthorized\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/custom-auth-call-api-with-unauthorized-token.png) La risposta indica che API Gateway restituisce una risposta **401 Unauthorized (401 Non autorizzato)** senza autorizzare la chiamata per l'accesso all'endpoint HTTP. 1. Modifica quindi il valore dell'intestazione del token di autorizzazione Lambda impostandolo su `fail`. Scegliere **Send (Invia)**. ![\[Chiamata di un'API con il token di autorizzazione Lambda fail\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/custom-auth-call-api-with-fail-token.png) La risposta indica che API Gateway restituisce una risposta **500 Internal Server Error (500 Errore interno del server)** senza autorizzare la chiamata per l'accesso all'endpoint HTTP. # Configurazione di un sistema di autorizzazione Lambda di Gateway API multi-account Ora puoi anche utilizzare una AWS Lambda funzione di un altro AWS account come funzione di autorizzazione dell'API. Ogni account può trovarsi in qualsiasi regione in cui è disponibile Amazon API Gateway. La funzione di autorizzazione Lambda può utilizzare strategie di autenticazione con token portatori come o SAML. OAuth Ciò semplifica la gestione e la condivisione centralizzate di una funzione di autorizzazione Lambda centrale su più API Gateway. APIs In questa sezione, viene illustrato come configurare un'autorizzazione Lambda tra account tramite la console Amazon API Gateway. Queste istruzioni presuppongono che tu abbia già un'API API Gateway in un AWS account e una funzione di autorizzazione Lambda in un altro account. ## Configurazione di un'autorizzazione Lambda tra account tramite la console API Gateway Accedi alla console Gateway Amazon API con l'account contenente la tua API e quindi procedi come descritto di seguito: 1. Scegli la tua API, quindi nel pannello di navigazione principale, scegli **Autorizzazioni**. 1. Scegli **Crea autorizzazioni**. 1. In **Nome del provider di autorizzazioni**, immetti il nome di un provider di autorizzazioni. 1. In **Tipo di autorizzazione**, seleziona **Lambda**. 1. In **Funzione Lambda**, copia e incolla l'ARN completo della funzione di autorizzazione Lambda nel secondo account. **Nota** Nella console Lambda, puoi trovare l'ARN della funzione nell'angolo in alto a destra. 1. Verrà visualizzato un avviso con una stringa del comando `aws lambda add-permission`. La policy concede a Gateway API l'autorizzazione per richiamare la funzione di autorizzazione Lambda. Copiare il comando e salvarlo per un secondo momento. È possibile eseguire il comando dopo aver creato l'autorizzatore. 1. In **Payload evento Lambda**, scegli **Token** per una funzione di autorizzazione basata su `TOKEN` o **Richiesta** per una funzione di autorizzazione basata su `REQUEST`. 1. A seconda dell'opzione scelta in precedenza, esegui una di queste operazioni: 1. Per l'opzione **Token** esegui le operazioni indicate di seguito: + In **Origine token**, immetti il nome dell'intestazione contenente il token di autorizzazione. Il client API deve includere un'intestazione con questo nome per inviare il token di autorizzazione all'autorizzazione Lambda. + Facoltativamente, per la **convalida del token**, inserisci una dichiarazione. RegEx API Gateway esegue la convalida iniziale del token di input per l'espressione e, se la convalida ha esito positivo, richiama l'autorizzazione. Ciò aiuta a ridurre le chiamate all'API. + Per memorizzare nella cache la policy di autorizzazione generata dalla funzione di autorizzazione, attiva l'opzione **Autorizzazione caching**. Quando la memorizzazione nella cache delle policy è abilitata, è possibile scegliere di modificare il valore **TTL**. L'impostazione dell'opzione **TTL** su zero disabilita la memorizzazione nella cache delle policy. Quando la memorizzazione della policy nella cache è abilitata, il nome dell'intestazione specificato in **Origine token** diventa la chiave della cache. Se nella richiesta vengono passati più valori a questa intestazione, tutti i valori diventeranno la chiave della cache, con l'ordine mantenuto. **Nota** Il valore **TTL** predefinito è 300 secondi. Il valore massimo è 3600 secondi e non è possibile aumentare questo limite. 1. Per l'opzione **Request (Richiesta)**, esegui queste operazioni: + In **Tipo di origine identità**, seleziona un tipo di parametro. I tipi di parametri supportati sono `Header`, `Query string`, `Stage variable` e `Context`. Per aggiungere altre origini di identità, scegli **Aggiungi parametro**. + Per memorizzare nella cache la policy di autorizzazione generata dalla funzione di autorizzazione, attiva l'opzione **Autorizzazione caching**. Quando la memorizzazione nella cache delle policy è abilitata, è possibile scegliere di modificare il valore **TTL**. L'impostazione dell'opzione **TTL** su zero disabilita la memorizzazione nella cache delle policy. API Gateway usa le origini di identità specificate come chiave di caching delle autorizzazioni della richiesta. Quando il caching è abilitato, API Gateway chiama la funzione di autorizzazione Lambda solo dopo aver verificato che tutte le origini di identità specificate siano presenti in fase di runtime. Se un’origine di identità specificata non è presente, è null o è vuota, Gateway API restituisce una risposta `401 Unauthorized` senza chiamare la funzione Lambda del sistema di autorizzazione. Quando sono definite più origini di identità, vengono utilizzate tutte per derivare la chiave cache delle autorizzazioni. Se vengono modificate parti della chiave cache, le autorizzazioni rimuovono il documento di policy memorizzato nella cache e ne generano uno nuovo. Se nella richiesta viene passata un'intestazione con più valori, tutti i valori diventeranno la chiave della cache, con l'ordine mantenuto. + Quando la memorizzazione nella cache è disattivata, non è necessario specificare un'origine di identità. **Nota** Per abilitare il caching, le autorizzazioni devono restituire una policy applicabile a tutti i metodi di un'API. Per applicare policy specifiche del metodo, puoi disattivare l'opzione **Autorizzazione caching**. 1. Scegli **Crea autorizzazioni**. 1. Incolla la stringa di `aws lambda add-permission` comando che hai copiato nel passaggio precedente in una AWS CLI finestra configurata per il tuo secondo account. Sostituire `AUTHORIZER_ID` con l'ID del proprio autorizzatore. In questo modo, al primo account verrà concesso l'accesso alla funzione di autorizzazione Lambda del secondo account. # Controllo dell'accesso in base agli attributi di un'identità con Autorizzazioni verificate Utilizza Autorizzazioni verificate da Amazon per controllare l'accesso alla tua API di Gateway API. Quando utilizzi Gateway API con Autorizzazioni verificate, Autorizzazioni verificate crea un sistema di autorizzazione Lambda che utilizza decisioni di autorizzazione granulari per controllare l'accesso alla tua API. Autorizzazioni verificate autorizza i chiamanti sulla base di uno schema di archivio di policy e di policy che utilizzano il linguaggio di policy Cedar per definire autorizzazioni granulari per gli utenti dell'applicazione. Per ulteriori informazioni, consulta [Creare un archivio di policy con un'API e un provider di identità connessi](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/getting-started-api-policy-store.html) nella *Guida per l'utente di Autorizzazioni verificate da Amazon*. Autorizzazioni verificate supporta i pool di utenti di Amazon Cognito o i provider di identità OpenID Connect (OIDC) come origini di identità. Autorizzazioni verificate presuppone che il principale sia stato precedentemente identificato e autenticato. Le autorizzazioni verificate sono supportate solo per REST regionali e ottimizzate per i dispositivi periferici. APIs ## Creazione di un sistema di autorizzazione Lambda con Autorizzazioni verificate Autorizzazioni verificate crea un sistema di autorizzazione Lambda per determinare se un principale è autorizzato a eseguire un'operazione sulla tua API. La policy Cedar utilizzata da Autorizzazioni verificate per eseguire le sue attività di autorizzazione viene creata da te. Di seguito è riportato un esempio di policy Cedar che consente l'accesso per invocare un'API in base al pool di utenti di Amazon Cognito`us-east-1_ABC1234`, per il gruppo `developer` sulla risorsa `GET /users` di un'API. Autorizzazioni verificate determina l'appartenenza al gruppo analizzando l'identità del chiamante nel token di connessione. ``` permit( principal in MyAPI::UserGroup::"us-east-1_ABC1234|developer", action in [ MyAPI::Action::"get /users" ], resource ); ``` Facoltativamente, Autorizzazioni verificate può collegare il sistema di autorizzazione ai metodi dell'API. Nelle fasi di produzione dell'API, è consigliabile non consentire ad Autorizzazioni verificate di collegare automaticamente il sistema di autorizzazione. L'elenco seguente mostra come configurare Autorizzazioni verificate per collegare o non collegare il sistema di autorizzazione Lambda alla richiesta di metodo dei metodi dell'API. **Sistema di autorizzazione collegato automaticamente (Console di gestione AWS)** Quando scegli **Crea archivio di policy** nella console Autorizzazioni verificate, nella pagina **Implementa integrazione app** scegli **Ora**. **Sistema di autorizzazione non collegato automaticamente (Console di gestione AWS)** Quando scegli **Crea archivio di policy** nella console Autorizzazioni verificate, nella pagina **Implementa integrazione app** scegli **Più tardi**. Autorizzazioni verificate crea comunque automaticamente un sistema di autorizzazione Lambda. Il sistema di autorizzazione Lambda inizia con `AVPAuthorizerLambda-`. Per ulteriori indicazioni su come collegare il sistema di autorizzazione per un metodo, consulta [Configurazione di un metodo per utilizzare un sistema di autorizzazione Lambda (console)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-console). **Sistema di autorizzazione collegato automaticamente (CloudFormation)** Nel CloudFormation modello generato da Autorizzazioni verificate, nella sezione, imposta su. `Conditions` `"Ref": "shouldAttachAuthorizer"` `true` **Sistema di autorizzazione non collegato automaticamente (CloudFormation)** Nel CloudFormation modello generato da Autorizzazioni verificate, nella sezione, imposta su. `Conditions` `"Ref": "shouldAttachAuthorizer"` `false` Autorizzazioni verificate crea comunque automaticamente un sistema di autorizzazione Lambda. Il sistema di autorizzazione Lambda inizia con `AVPAuthorizerLambda-`. Per ulteriori indicazioni su come collegare il sistema di autorizzazione per un metodo, consulta [Configurazione di un metodo per utilizzare un sistema di autorizzazione Lambda (AWS CLI)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-cli). ## Chiamata di un sistema di autorizzazione Lambda con Autorizzazioni verificate Puoi chiamare il tuo sistema di autorizzazione Lambda specificando un'identità o un token di accesso nell'intestazione `Authorization`. Per ulteriori informazioni, consulta [Chiamata di un'API con il sistema di autorizzazione Lambda di Gateway API](call-api-with-api-gateway-lambda-authorization.md). Gateway API memorizza nella cache la policy restituita dal sistema di autorizzazione Lambda per 120 secondi. È possibile modificare il TTL nella console Gateway API o tramite AWS CLI.