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à. # Configurazione dell'autorizzazione e dell'autenticazione per proteggere GraphQL APIs AWS AppSync offre i seguenti tipi di autorizzazione per proteggere GraphQL APIs: chiavi API, Lambda, IAM, OpenID Connect e Cognito User Pools. Ogni opzione offre un metodo di sicurezza diverso: 1. **Autorizzazione tramite chiave API**: controlla la limitazione per i non autenticati APIs, fornendo una semplice opzione di sicurezza. 1. **Autorizzazione Lambda**: abilita la logica di autorizzazione personalizzata, spiegando in dettaglio gli input e gli output delle funzioni. 1. **Autorizzazione IAM**: utilizza il processo AWS di firma della versione 4 della firma, che consente un controllo granulare degli accessi tramite le policy IAM. 1. **Autorizzazione OpenID Connect**: si integra con i servizi conformi a OIDC per l'autenticazione degli utenti. 1. **Pool di utenti Cognito**: implementa il controllo degli accessi basato sul gruppo utilizzando le funzionalità di gestione degli utenti di Cognito. ## Tipi di autorizzazione Esistono cinque modi per autorizzare le applicazioni a interagire con l'API AWS AppSync GraphQL. È possibile specificare il tipo di autorizzazione da utilizzare specificando uno dei seguenti valori del tipo di autorizzazione nella chiamata AWS AppSync API o CLI: + ** `API_KEY` ** Per usare chiavi API. + ** `AWS_LAMBDA` ** Per usare una AWS Lambda funzione. + ** `AWS_IAM` ** Per l'utilizzo delle autorizzazioni AWS Identity and Access Management ([IAM](https://aws.amazon.com/iam/)). + ** `OPENID_CONNECT` ** Per usare il provider OpenID Connect. + ** `AMAZON_COGNITO_USER_POOLS` ** Per l'utilizzo di un pool di utenti Amazon Cognito. Questi tipi di autorizzazione di base funzionano per la maggior parte degli sviluppatori. Per casi d'uso più avanzati, puoi aggiungere modalità di autorizzazione aggiuntive tramite la console, la CLI e. AWS CloudFormation Per le modalità di autorizzazione aggiuntive, AWS AppSync fornisce un tipo di autorizzazione che accetta i valori sopra elencati (ovvero`API_KEY`,`AWS_LAMBDA`, `AWS_IAM``OPENID_CONNECT`, e`AMAZON_COGNITO_USER_POOLS`). Quando si specifica `API_KEY``AWS_LAMBDA`, o `AWS_IAM` come tipo di autorizzazione principale o predefinito, non è possibile specificarli nuovamente come una delle modalità di autorizzazione aggiuntive. Allo stesso modo, non è possibile duplicare `API_KEY` `AWS_LAMBDA` o `AWS_IAM` inserire le modalità di autorizzazione aggiuntive. Puoi utilizzare più pool di utenti Amazon Cognito e provider OpenID Connect. Tuttavia, non puoi utilizzare pool di utenti Amazon Cognito o provider OpenID Connect duplicati tra la modalità di autorizzazione predefinita e nessuna delle modalità di autorizzazione aggiuntive. Puoi specificare diversi client per il tuo pool di utenti Amazon Cognito o il provider OpenID Connect utilizzando l'espressione regolare di configurazione corrispondente. Quando salvi le modifiche alla configurazione dell'API, AWS AppSync inizia a propagare le modifiche. Fino a quando la modifica alla configurazione non viene propagata, AWS AppSync continua a fornire i contenuti della configurazione precedente. Dopo la propagazione della modifica alla configurazione, inizia AWS AppSync immediatamente a pubblicare i contenuti in base alla nuova configurazione. Durante AWS AppSync la propagazione delle modifiche per un'API, non possiamo determinare se l'API sta servendo i tuoi contenuti sulla base della configurazione precedente o della nuova configurazione. ## API\_KEY autorizzazione I non autenticati APIs richiedono una limitazione più rigorosa di quelli autenticati. APIs Un modo per controllare il throttling per gli endpoint GraphQL non autenticati è l'uso di chiavi API. Un chiave API è un valore hardcoded nell'applicazione che viene generato dal servizio AWS AppSync quando crei un endpoint GraphQL non autenticato. Puoi ruotare le chiavi API dalla console, dalla CLI o [AWS AppSync dal](https://docs.aws.amazon.com/appsync/latest/APIReference/) riferimento API. ------ #### [ Console ] 1. [Accedi Console di gestione AWS e apri la AppSync console.](https://console.aws.amazon.com/appsync/) 1. Nella **APIs dashboard**, scegli la tua API GraphQL. 1. **Nella **barra laterale**, scegli Impostazioni.** 1. In **Modalità di autorizzazione predefinita**, scegli la **chiave API**. 1. Nella tabella delle **chiavi API**, scegli **Aggiungi chiave API**. Nella tabella verrà generata una nuova chiave API. 1. Per eliminare una vecchia chiave API, seleziona la chiave API nella tabella, quindi scegli **Elimina**. 1. Scegli **Save** (Salva) nella parte inferiore della pagina. ------ #### [ CLI ] 1. Se non l'hai già fatto, configura il tuo accesso alla AWS CLI. Per ulteriori informazioni, consulta Nozioni di [base sulla configurazione](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html). 1. Crea un oggetto API GraphQL eseguendo il [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html)comando. Dovrai digitare due parametri per questo particolare comando: 1. La tua `api-id` API GraphQL. 1. La novità `name` della tua API. Puoi usare lo stesso`name`. 1. Il`authentication-type`, che sarà`API_KEY`. **Nota** Esistono altri parametri come questi `Region` che devono essere configurati, ma di solito vengono utilizzati per impostazione predefinita i valori di configurazione CLI. Un comando di esempio può avere il seguente aspetto: ``` aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY ``` Verrà restituito un output nella CLI. Ecco un esempio in JSON: ``` { "graphqlApi": { "xrayEnabled": false, "name": "TestAPI", "authenticationType": "API_KEY", "tags": {}, "apiId": "abcdefghijklmnopqrstuvwxyz", "uris": { "GRAPHQL": "https://s8i3kk3ufhe9034ujnv73r513e.appsync-api.us-west-2.amazonaws.com/graphql", "REALTIME": "wss://s8i3kk3ufhe9034ujnv73r513e.appsync-realtime-api.us-west-2.amazonaws.com/graphql" }, "arn": "arn:aws:appsync:us-west-2:348581070237:apis/abcdefghijklmnopqrstuvwxyz" } } ``` ------ Le chiavi API sono configurabili per un massimo di 365 giorni e puoi estendere una data di scadenza esistente per un massimo di altri 365 giorni dalla data di scadenza. Le chiavi API sono consigliate per scopi di sviluppo o casi d'uso in cui è sicuro esporre un'API pubblica. Nel client la chiave API viene specificata dall'intestazione `x-api-key`. Ad esempio, se `API_KEY` è `'ABC123'`, puoi inviare una query GraphQL tramite `curl` in questo modo: ``` $ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql ``` ## AWS\_LAMBDA autorizzazione È possibile implementare la propria logica di autorizzazione API utilizzando una AWS Lambda funzione. È possibile utilizzare una funzione Lambda per l'autorizzatore principale o secondario, ma può esserci una sola funzione di autorizzazione Lambda per API. Quando si utilizzano le funzioni Lambda per l'autorizzazione, si applica quanto segue: + Se l'API ha le modalità `AWS_LAMBDA` e `AWS_IAM` autorizzazione abilitate, la firma SigV4 non può essere utilizzata come token di autorizzazione. `AWS_LAMBDA` + Se l'API ha le modalità di `OPENID_CONNECT` autorizzazione `AWS_LAMBDA` e o la modalità di `AMAZON_COGNITO_USER_POOLS` autorizzazione abilitata, il token OIDC non può essere utilizzato come token di autorizzazione. `AWS_LAMBDA` Nota che il token OIDC può essere uno schema Bearer. + Una funzione Lambda non deve restituire più di 5 MB di dati contestuali per i resolver. Ad esempio, se il token di autorizzazione è`'ABC123'`, puoi inviare una query GraphQL tramite curl come segue: ``` $ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql ``` Le funzioni Lambda vengono chiamate prima di ogni query o mutazione. Il valore restituito può essere memorizzato nella cache in base all'ID API e al token di autenticazione. Quando una risposta di autorizzazione Lambda è inferiore a 1.048.576 byte, AWS AppSync memorizza nella cache la risposta per le richieste successive. Se la risposta dell'autorizzazione Lambda è uguale o superiore a 1.048.576 byte, AWS AppSync non memorizza nella cache la risposta e richiama l'autorizzazione Lambda per ogni richiesta in arrivo. Per ottimizzare le prestazioni e ridurre al minimo i costi di chiamata Lambda, consigliamo di limitare le risposte dell'autorizzazione Lambda a 1.048.576 byte. Per impostazione predefinita, la memorizzazione nella cache non è attivata, ma può essere abilitata a livello di API o impostando il valore nel valore restituito da una funzione. `ttlOverride` Se lo si desidera, è possibile specificare un'espressione regolare che convalida i token di autorizzazione prima della chiamata della funzione. Queste espressioni regolari vengono utilizzate per verificare che un token di autorizzazione sia del formato corretto prima che la funzione venga chiamata. Qualsiasi richiesta che utilizza un token che non corrisponde a questa espressione regolare verrà rifiutata automaticamente. Le funzioni Lambda utilizzate per l'autorizzazione richiedono l'applicazione `appsync.amazonaws.com` di una politica principale per consentire di AWS AppSync chiamarle. Questa azione viene eseguita automaticamente nella AWS AppSync console; la AWS AppSync console *non* rimuove la policy. Per ulteriori informazioni sull'associazione di policy alle funzioni Lambda, [consulta Politiche basate sulle risorse](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) nella Developer Guide. AWS Lambda La funzione Lambda specificata riceverà un evento con la forma seguente: ``` { "authorizationToken": "ExampleAUTHtoken123123123", "requestContext": { "apiId": "aaaaaa123123123example123", "accountId": "111122223333", "requestId": "f4081827-1111-4444-5555-5cf4695f339f", "queryString": "mutation CreateEvent {...}\n\nquery MyQuery {...}\n", "operationName": "MyQuery", "variables": {} } "requestHeaders": { {{application request headers}} } } ``` L'`event`oggetto contiene le intestazioni che sono state inviate nella richiesta dal client dell'applicazione a. AWS AppSync La funzione di autorizzazione deve restituire almeno `isAuthorized` un valore booleano che indica se la richiesta è autorizzata. AWS AppSync riconosce le seguenti chiavi restituite dalle funzioni di autorizzazione Lambda: **Nota** Il valore per l'operazione `operationName` in the `requestContext` for a WebSocket connect è impostato su "»`DeepDish:Connect`. AWS AppSync ### Elenco delle funzioni `isAuthorized`(booleano, obbligatorio) Un valore booleano che indica se il valore in `authorizationToken` è autorizzato a effettuare chiamate all'API GraphQL. Se questo valore è vero, l'esecuzione dell'API GraphQL continua. Se questo valore è falso, `UnauthorizedException` viene generato un `deniedFields`(elenco di stringhe, opzionale) Un elenco dei quali viene modificato forzatamente in`null`, anche se un valore è stato restituito da un resolver. Ogni articolo è un ARN di campo completamente qualificato sotto forma di `arn:aws:appsync:{{us-east-1}}:{{111122223333}}:apis/{{GraphQLApiId}}/types/{{TypeName}}/fields/{{FieldName}}` o in forma abbreviata di. `{{TypeName}}.{{FieldName}}` Il modulo ARN completo deve essere usato quando due APIs condividono un autorizzatore di funzione Lambda e potrebbero esserci ambiguità tra i tipi e i campi comuni tra i due. APIs `resolverContext`(Oggetto JSON, opzionale) Un oggetto JSON visibile come `$ctx.identity.resolverContext` nei modelli di resolver. Ad esempio, se un resolver restituisce la seguente struttura: ``` { "isAuthorized":true "resolverContext": { "banana":"very yellow", "apple":"very green" } } ``` Il valore dei modelli `ctx.identity.resolverContext.apple` di resolver sarà "». `very green` L'`resolverContext`oggetto supporta solo coppie chiave-valore. Le chiavi annidate non sono supportate. La dimensione totale di questo oggetto JSON non deve superare i 5 MB. `ttlOverride`(numero intero, opzionale) Il numero di secondi per i quali la risposta deve essere memorizzata nella cache. Se non viene restituito alcun valore, viene utilizzato il valore dell'API. Se è 0, la risposta non viene memorizzata nella cache. Le autorizzazioni Lambda hanno un timeout standard di 10 secondi, ma possono scadere prima in condizioni di traffico intenso. Ti consigliamo di progettare funzioni da eseguire nel minor tempo possibile (meno di 1 secondo) per scalare le prestazioni dell'API. Più persone AWS AppSync APIs possono condividere una singola funzione Lambda di autenticazione. L'uso di un sistema di autorizzazione tra account non è consentito. Quando condividete una funzione di autorizzazione tra più persone APIs, tenete presente che i nomi di campo in formato breve (`{{typename}}.{{fieldname}}`) possono inavvertitamente nascondere dei campi. Per disambiguare un campo in`deniedFields`, è possibile specificare un campo non ambiguo ARN sotto forma di. `arn:aws:appsync:{{region}}:{{accountId}}:apis/{{GraphQLApiId}}/types/{{typeName}}/fields/{{fieldName}}` Per aggiungere una funzione Lambda come modalità di autorizzazione predefinita in: AWS AppSync ------ #### [ Console ] 1. Accedi alla AWS AppSync console e vai all'API che desideri aggiornare. 1. Vai alla pagina Impostazioni della tua API. Cambia l'autorizzazione a livello di API in. **AWS Lambda** 1. Scegli l'ARN Regione AWS e Lambda per autorizzare le chiamate API. **Nota** La politica principale appropriata verrà aggiunta automaticamente, consentendo di AWS AppSync chiamare la funzione Lambda. 1. Facoltativamente, imposta il TTL di risposta e l'espressione regolare di convalida del token. ------ #### [ AWS CLI ] 1. Allega la seguente policy alla funzione Lambda in uso: ``` aws lambda add-permission --function-name "{{my-function}}" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text ``` **Importante** Se desideri che la politica della funzione sia bloccata su una singola API GraphQL, puoi eseguire questo comando: ``` aws lambda add-permission --function-name “{{my-function}}” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “{{}}” --output text ``` 1. Aggiorna la tua AWS AppSync API per utilizzare la funzione Lambda ARN specificata come autorizzatore: ``` aws appsync update-graphql-api --api-id {{example2f0ur2oid7acexample}} --name {{exampleAPI}} --authentication-type AWS_LAMBDA --lambda-authorizer-config authorizerUri="{{arn:aws:lambda:us-east-2:111122223333:function:my-function}}" ``` **Nota** Puoi anche includere altre opzioni di configurazione come l'espressione regolare del token. ------ L'esempio seguente descrive una funzione Lambda che dimostra i vari stati di autenticazione e di errore che una funzione Lambda può avere quando viene utilizzata come meccanismo di autorizzazione: AWS AppSync ``` def handler(event, context): # This is the authorization token passed by the client token = event.get('authorizationToken') # If a lambda authorizer throws an exception, it will be treated as unauthorized. if 'Fail' in token: raise Exception('Purposefully thrown exception in Lambda Authorizer.') if 'Authorized' in token and 'ReturnContext' in token: return { 'isAuthorized': True, 'resolverContext': { 'key': 'value' } } # Authorized with no f if 'Authorized' in token: return { 'isAuthorized': True } # Partial authorization if 'Partial' in token: return { 'isAuthorized': True, 'deniedFields':['user.favoriteColor'] } if 'NeverCache' in token: return { 'isAuthorized': True, 'ttlOverride': 0 } if 'Unauthorized' in token: return { 'isAuthorized': False } # if nothing is returned, then the authorization fails. return {} ``` ### Eludere le limitazioni di autorizzazione dei token SigV4 e OIDC I seguenti metodi possono essere utilizzati per aggirare il problema dell'impossibilità di utilizzare la firma SigV4 o il token OIDC come token di autorizzazione Lambda quando sono abilitate determinate modalità di autorizzazione. Se desideri utilizzare la firma SigV4 come token di autorizzazione Lambda quando le modalità di autorizzazione `AWS_IAM` e le modalità di `AWS_LAMBDA` autorizzazione sono abilitate per l'API, AWS AppSync procedi come segue: + Per creare un nuovo token di autorizzazione Lambda, aggiungi and/or prefissi di suffissi casuali alla firma SigV4. + Per recuperare la firma SigV4 originale, aggiorna la funzione Lambda rimuovendo i and/or suffissi casuali dei prefissi dal token di autorizzazione Lambda. Quindi, usa la firma SigV4 originale per l'autenticazione. Se desideri utilizzare il token OIDC come token di autorizzazione Lambda quando la modalità di autorizzazione o le modalità di `OPENID_CONNECT` `AWS_LAMBDA` autorizzazione `AMAZON_COGNITO_USER_POOLS` e sono abilitate per l'API, AWS AppSync procedi come segue: + Per creare un nuovo token di autorizzazione Lambda, aggiungi and/or prefissi di suffissi casuali al token OIDC. Il token di autorizzazione Lambda non deve contenere un prefisso dello schema Bearer. + Per recuperare il token OIDC originale, aggiorna la funzione Lambda rimuovendo i and/or suffissi dei prefissi casuali dal token di autorizzazione Lambda. Quindi, usa il token OIDC originale per l'autenticazione. ## AWS\_IAM autorizzazione Questo tipo di autorizzazione applica il [processo di AWS firma della versione 4 della firma sull'API](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) GraphQL. È possibile associare policy d'accesso Identity and Access Management ([IAM](https://aws.amazon.com/iam/)) a questo tipo di autorizzazione. La tua applicazione può sfruttare questa associazione utilizzando una chiave di accesso (che consiste in un ID chiave di accesso e una chiave di accesso segreta) o utilizzando credenziali temporanee di breve durata fornite da Amazon Cognito Federated Identities. Se vuoi usare un ruolo che abbia accesso per eseguire tutte le operazioni sui dati: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*" ] } ] } ``` ------ Puoi trovarla `YourGraphQLApiId` dalla pagina principale dell'elenco delle API nella AppSync console, direttamente sotto il nome della tua API. In alternativa, puoi recuperarlo con l'interfaccia a riga di comando: `aws appsync list-graphql-apis` Se vuoi limitare l'accesso solo a determinate operazioni GraphQL, puoi farlo per i campi root `Query`, `Mutation` e `Subscription`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/" ] } ] } ``` ------ Ad esempio, supponiamo la presenza dello schema seguente e di voler limitare l'accesso in modo da ottenere tutti i post: ``` schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! } ``` La politica IAM corrispondente per un ruolo (che puoi collegare a un pool di identità di Amazon Cognito, ad esempio) sarebbe simile alla seguente: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/posts" ] } ] } ``` ------ ## OPENID\_CONNECT autorizzazione Questo tipo di autorizzazione applica i token [OpenID](https://openid.net/specs/openid-connect-core-1_0.html) connect (OIDC) forniti da un servizio conforme a OIDC. La tua applicazione può usare gli utenti e i privilegi definiti dal provider OIDC per controllare l'accesso. Un URL dell'emittente è l'unico valore di configurazione necessario da fornire ad AWS AppSync, ad esempio `https://auth.example.com`. Questo URL deve essere indirizzabile tramite HTTPS. AWS AppSync [aggiunge `/.well-known/openid-configuration` all'URL dell'emittente e individua la configurazione OpenID in base alla specifica OpenID Connect `https://auth.example.com/.well-known/openid-configuration` Discovery.](https://openid.net/specs/openid-connect-discovery-1_0.html) Si aspetta di recuperare un [RFC5785](https://tools.ietf.org/html/rfc5785)documento JSON conforme a questo URL. Questo documento JSON deve contenere una `jwks_uri` chiave che rimanda al documento JSON Web Key Set (JWKS) con le chiavi di firma. AWS AppSync richiede che JWKS contenga campi JSON di e. `kty` `kid` AWS AppSync supporta un'ampia gamma di algoritmi di firma. | Algoritmi di firma | | --- | | RS256 | | RS384 | | RS512 | | PS256 | | PS384 | | PS512 | | HS256 | | HS384 | | HS512 | | ES256 | | ES384 | | ES512 | Si consiglia di utilizzare gli algoritmi RSA. I token emessi dal provider devono includere la data e l'ora di emissione del token (`iat`) e possono includere la data e l'ora in cui è stato autenticato (`auth_time`). Puoi specificare valori TTL per la data e l'ora di emissione (`iatTTL`) e di autenticazione (`authTTL`) nella configurazione OpenID Connect per un'ulteriore convalida. Se il provider autorizza più applicazioni, puoi anche immettere un'espressione regolare (`clientId`), usata per l'autorizzazione tramite ID client. Quando `clientId` è presente nella configurazione di OpenID Connect, AWS AppSync convalida l'affermazione richiedendo che corrisponda `clientId` all'`azp`affermazione `aud` o nel token. Per convalidare più client, IDs usa l'operatore pipeline («\|») che è un «o» nell'espressione regolare. Ad esempio, se l'applicazione OIDC ha quattro client con client IDs come 0A1S2D, 1F4G9H, 1J6L4B, 6 GS5 MG, per convalidare solo i primi tre client IDs, è necessario inserire GS5 1F4G9H\|1J6L4B\|6 MG nel campo ID client. Se un'API è configurata con più tipi di autorizzazione, AWS AppSync convalida l'emittente (iss claim) presente nel token JWT dalle intestazioni della richiesta confrontandolo con l'URL dell'emittente specificato nella configurazione dell'API. Tuttavia, quando un'API è configurata solo con OPENID\_CONNECT autorizzazione, AWS AppSync salta questa fase di convalida dell'URL dell'emittente. ## AMAZON\_COGNITO\_USER\_POOLS autorizzazione Questo tipo di autorizzazione applica i token OIDC forniti dai pool di utenti di Amazon Cognito. L'applicazione può sfruttare gli utenti e i gruppi presenti nei pool di utenti e nei pool di utenti di un altro AWS account e associarli ai campi GraphQL per controllare l'accesso. Quando usi i pool di utenti di Amazon Cognito, puoi creare gruppi a cui appartengono gli utenti. Queste informazioni sono codificate in un token JWT a cui l'applicazione invia AWS AppSync in un'intestazione di autorizzazione durante l'invio di operazioni GraphQL. Puoi usare direttive GraphQL nello schema per controllare quali gruppi possono richiamare resolver specifici in un campo, per offrire un accesso più controllato ai tuoi clienti. Ad esempio, supponiamo lo schema GraphQL seguente: ``` schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! } ... ``` Se hai due gruppi nei pool di utenti di Amazon Cognito, blogger e lettori, e desideri limitare i lettori in modo che non possano aggiungere nuove voci, lo schema dovrebbe essere simile al seguente: ``` schema { query: Query mutation: Mutation } ``` ``` type Query { posts:[Post!]! @aws_auth(cognito_groups: ["Bloggers", "Readers"]) } type Mutation { addPost(id:ID!, title:String!):Post! @aws_auth(cognito_groups: ["Bloggers"]) } ... ``` Tieni presente che puoi omettere la `@aws_auth` direttiva se desideri impostare di default una grant-or-deny strategia di accesso specifica. È possibile specificare la grant-or-deny strategia nella configurazione del pool di utenti quando si crea l'API GraphQL tramite la console o tramite il seguente comando CLI: ``` $ aws appsync --region us-west-2 create-graphql-api --authentication-type AMAZON_COGNITO_USER_POOLS --name userpoolstest --user-pool-config '{ "userPoolId":"test", "defaultEffect":"ALLOW", "awsRegion":"us-west-2"}' ``` ## Utilizzo di modalità di autorizzazione aggiuntive Quando aggiungi modalità di autorizzazione aggiuntive, puoi configurare direttamente l'impostazione di autorizzazione a livello di API AWS AppSync GraphQL (ovvero, il `authenticationType` campo che puoi configurare direttamente sull'`GraphqlApi`oggetto) e funge da impostazione predefinita sullo schema. Ciò significa che qualsiasi tipo che non dispone di una direttiva specifica deve superare l'impostazione di autorizzazione a livello di API. A livello di schema, puoi specificare ulteriori modalità di autorizzazione utilizzando le direttive sullo schema. Puoi specificare le modalità di autorizzazione su singoli campi nello schema. Ad esempio, per l’autorizzazione `API_KEY` puoi utilizzare `@aws_api_key` nelle definizioni/campi del tipo di oggetto dello schema. Le direttive seguenti sono supportate nei campi dello schema e nelle definizioni del tipo di oggetto: + `@aws_api_key` - Per specificare che il campo è autorizzato `API_KEY`. + `@aws_iam` - Per specificare che il campo è autorizzato `AWS_IAM`. + `@aws_oidc` - Per specificare che il campo è autorizzato `OPENID_CONNECT`. + `@aws_cognito_user_pools` - Per specificare che il campo è autorizzato `AMAZON_COGNITO_USER_POOLS`. + `@aws_lambda` - Per specificare che il campo è autorizzato `AWS_LAMBDA`. Non puoi utilizzare la direttiva `@aws_auth` insieme a modalità di autorizzazione aggiuntive. `@aws_auth` funziona solo nel contesto dell'autorizzazione `AMAZON_COGNITO_USER_POOLS` senza modalità di autorizzazione aggiuntive. Tuttavia, puoi utilizzare la direttiva `@aws_cognito_user_pools` al posto della direttiva `@aws_auth`, utilizzando gli stessi argomenti. La differenza principale tra le due è che è possibile specificare `@aws_cognito_user_pools` in qualsiasi definizione di campo e tipo di oggetto. Per comprendere come funzionano le modalità di autorizzazione aggiuntive e come possono essere specificate in uno schema, esaminiamo lo schema seguente: ``` schema { query: Query mutation: Mutation } type Query { getPost(id: ID): Post getAllPosts(): [Post] @aws_api_key } type Mutation { addPost( id: ID! author: String! title: String! content: String! url: String! ): Post! } type Post @aws_api_key @aws_iam { id: ID! author: String title: String content: String url: String ups: Int! downs: Int! version: Int! } ... ``` Per questo schema, supponiamo che `AWS_IAM` sia il tipo di autorizzazione predefinito sull'API AWS AppSync GraphQL. Ciò significa che i campi che non dispongono di una direttiva sono protetti utilizzando `AWS_IAM`. Ad esempio, questo è il caso del campo `getPost` sul tipo `Query`. Le direttive dello schema consentono di utilizzare più di una modalità di autorizzazione. Ad esempio, è possibile `API_KEY` configurarla come modalità di autorizzazione aggiuntiva sull'API AWS AppSync GraphQL e contrassegnare un campo utilizzando la `@aws_api_key` direttiva (ad esempio, `getAllPosts` in questo esempio). Le direttive funzionano a livello di campo, quindi è necessario concedere a `API_KEY` l'accesso anche al tipo `Post`. Puoi eseguire questa operazione contrassegnando ogni campo nel tipo `Post` con una direttiva oppure contrassegnando il tipo `Post` con la direttiva `@aws_api_key`. Per limitare ulteriormente l'accesso ai campi nel tipo `Post`, puoi utilizzare le direttive sui singoli campi nel tipo `Post` come mostrato di seguito. Ad esempio, puoi aggiungere un campo `restrictedContent` al tipo `Post` e limitare l'accesso utilizzando la direttiva `@aws_iam`. Le richieste autenticate `AWS_IAM` possono accedere a `restrictedContent`, mentre le richieste `API_KEY` non possono accedervi. ``` type Post @aws_api_key @aws_iam{ id: ID! author: String title: String content: String url: String ups: Int! downs: Int! version: Int! restrictedContent: String! @aws_iam } ... ``` ## Controllo granulare degli accessi Le informazioni precedenti descrivono come limitare o concedere l'accesso a determinati campi GraphQL. Se vuoi impostare controlli degli accessi sui dati in base a determinate condizioni (ad esempio in base all'utente che effettua una chiamata e se è il proprietario dei dati), puoi usare i modelli di mappatura nei resolver. Puoi anche eseguire una logica di business più complessa, che descriveremo in [Applicazione di filtri alle informazioni](#aws-appsync-filtering-information). Questa sezione mostra come impostare i controlli di accesso sui dati utilizzando un modello di mappatura del resolver DynamoDB. Prima di procedere oltre, se non hai dimestichezza con i modelli di mappatura in AWS AppSync, potresti voler consultare il riferimento al modello di mappatura [Resolver e il riferimento al modello di mappatura](resolver-mapping-template-reference.md#aws-appsync-resolver-mapping-template-reference) [Resolver](resolver-mapping-template-reference-dynamodb.md#aws-appsync-resolver-mapping-template-reference-dynamodb) per DynamoDB. Nell'esempio seguente che utilizza DynamoDB, supponiamo di utilizzare lo schema di post del blog precedente e che solo gli utenti che hanno creato un post siano autorizzati a modificarlo. Il processo di valutazione ha lo scopo di permettere all'utente di ottenere le credenziali nell'applicazione, ad esempio usando pool di utenti Amazon Cognito, e quindi passare queste credenziali come parte di un'operazione GraphQL. Il modello di mappatura sostituisce quindi un valore delle credenziali, ad esempio il nome utente, in un'istruzione condizionale, che viene quindi confrontata con un valore nel database. ![Flusso di lavoro in quattro fasi che mostra il recupero dei token, l'invio delle richieste, il controllo condizionale e l'esecuzione delle operazioni.](http://docs.aws.amazon.com/it_it/appsync/latest/devguide/images/FGAC.png) Per aggiungere questa funzionalità, aggiungi un campo GraphQL `editPost` in questo modo: ``` schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { editPost(id:ID!, title:String, content:String):Post addPost(id:ID!, title:String!):Post! } ... ``` Il modello di mappatura dei resolver per `editPost` (mostrato in un esempio alla fine di questa sezione) deve eseguire un controllo logico sul datastore per permettere solo all'utente che ha creato un post di modificarlo. Poiché si tratta di un'operazione di modifica, corrisponde a un'operazione `UpdateItem` in DynamoDB. Puoi eseguire un controllo condizionale prima di eseguire questa operazione, usando il contesto passato per la convalida dell'identità dell'utente. Questo viene archiviato in un oggetto `Identity` che ha i valori seguenti: ``` { "accountId" : "12321434323", "cognitoIdentityPoolId" : "", "cognitoIdentityId" : "", "sourceIP" : "", "caller" : "ThisistheprincipalARN", "username" : "username", "userArn" : "Sameasabove" } ``` Per utilizzare questo oggetto in una chiamata `UpdateItem` DynamoDB, è necessario memorizzare le informazioni sull'identità dell'utente nella tabella per il confronto. Prima di tutto, la mutazione `addPost` deve archiviare l'autore. In secondo luogo, la mutazione `editPost` deve eseguire il controllo condizionale prima dell'aggiornamento. Ecco un esempio di codice del resolver `addPost` che memorizza l'identità dell'utente come colonna: `Author` ``` import { util, Context } from '@aws-appsync/utils'; import { put } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const { id: postId, ...item } = ctx.args; return put({ key: { postId }, item: { ...item, Author: ctx.identity.username }, condition: { postId: { attributeExists: false } }, }); } export const response = (ctx) => ctx.result; ``` Nota che l'attributo `Author` viene popolato dall'oggetto `Identity`, che proviene dall'applicazione. Infine, ecco un esempio del codice resolver for`editPost`, che aggiorna il contenuto del post sul blog solo se la richiesta proviene dall'utente che ha creato il post: ``` import { util, Context } from '@aws-appsync/utils'; import { put } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const { id, ...item } = ctx.args; return put({ key: { id }, item, condition: { author: { contains: ctx.identity.username } }, }); } export const response = (ctx) => ctx.result; ``` Questo esempio utilizza un `PutItem` che sovrascrive tutti i valori anziché uno`UpdateItem`, ma lo stesso concetto si applica al `condition` blocco di istruzioni. ## Filtraggio delle informazioni Esistono alcuni casi in cui non puoi controllare la risposta proveniente dall'origine dati, ma non vuoi inviare informazioni inutili ai client in un'operazione di scrittura o lettura riuscita nell'origine dati. In questi casi, puoi filtrare le informazioni usando un modello di mappatura della risposta. Ad esempio, supponiamo di non avere un indice appropriato nella tabella DynamoDB del post sul blog (ad esempio un indice su). `Author` Puoi usare il seguente resolver: ``` import { util, Context } from '@aws-appsync/utils'; import { get } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { return get({ key: { ctx.args.id } }); } export function response(ctx) { if (ctx.result.author === ctx.identity.username) { return ctx.result; } return null; } ``` Il gestore della richiesta recupera l'elemento anche se il chiamante non è l'autore che ha creato il post. Per evitare che ciò restituisca tutti i dati, il gestore della risposta verifica che il chiamante corrisponda all'autore dell'elemento. Se il chiamante non corrisponde a questo controllo, viene restituita solo una risposta Null. ## Accesso origine dati AWS AppSync comunica con le fonti di dati utilizzando i ruoli e le policy di accesso di Identity and Access Management ([IAM](https://aws.amazon.com/iam/)). Se si utilizza un ruolo esistente, è necessario aggiungere una politica di fiducia per AWS AppSync assumere il ruolo. La relazione di attendibilità apparirà come segue: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appsync.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ È importante ridurre l'ambito della policy di accesso sul ruolo per avere solo le autorizzazioni per agire sul set minimo di risorse necessarie. Quando si utilizza la AppSync console per creare un'origine dati e creare un ruolo, questa operazione viene eseguita automaticamente. Tuttavia, quando si utilizza un modello di esempio integrato dalla console IAM per creare un ruolo al di fuori della console AWS AppSync, non sarà automaticamente ridotto l'ambito dei permessi su una risorsa; si consiglia di eseguire questa azione prima di spostare l'applicazione in produzione.