Tipi di autorizzazione Autorizzazione API_KEY Autorizzazione AWS_LAMBDA Autorizzazione AWS_IAM Autorizzazione OPENID_CONNECT Autorizzazione AMAZON_COGNITO_USER_POOLS Utilizzo di modalità di autorizzazione aggiuntive Fine-grained controllo degli accessi Filtraggio delle informazioni Accesso origine dati

Configurazione dell'autorizzazione e dell'autenticazione per proteggere le API GraphQL

AWS AppSync offre i seguenti tipi di autorizzazione per proteggere le API GraphQL: chiavi API, Lambda, IAM, OpenID Connect e pool di utenti Cognito. Ogni opzione fornisce un metodo di sicurezza diverso:

Autorizzazione con chiave API: controlla la limitazione delle API non autenticate, fornendo una semplice opzione di sicurezza.
Autorizzazione Lambda: abilita una logica di autorizzazione personalizzata, spiegando in dettaglio gli input e gli output delle funzioni.
Autorizzazione IAM: utilizza il processo AWS di firma della versione 4, che consente un controllo granulare degli accessi tramite politiche IAM.
Autorizzazione OpenID Connect: si integra con i servizi per l'autenticazione degli utenti. OIDC-compliant
Pool di utenti Cognito: implementa il controllo degli accessi basato sui gruppi 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. Specificate il tipo di autorizzazione da utilizzare specificando uno dei seguenti valori del tipo di autorizzazione nella vostra chiamata AWS AppSync API o CLI:

API_KEY

Per usare chiavi API.
AWS_LAMBDA

Per usare una AWS Lambda funzione.
AWS_IAM

Per utilizzare le autorizzazioni AWS Identity and Access Management (IAM).
OPENID_CONNECT

Per usare il provider OpenID Connect.
AMAZON_COGNITO_USER_POOLS

Per utilizzare 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 modalità di autorizzazione aggiuntive, AWS AppSync fornisce un tipo di autorizzazione che accetta i valori sopra elencati (ovvero,API_KEY,AWS_LAMBDA, AWS_IAMOPENID_CONNECT, eAMAZON_COGNITO_USER_POOLS).

Quando si specifica API_KEYAWS_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 utilizzare AWS_IAM 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 una 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. Finché la modifica della configurazione non viene propagata, AWS AppSync continua a pubblicare 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 in base alla configurazione precedente o alla nuova configurazione.

Autorizzazione API_KEY

Le API non autenticate richiedono un throttling più rigoroso rispetto alle API autenticate. 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 dal riferimento API. AWS AppSync

Console

Accedi Console di gestione AWS e apri la AppSync console.
1. Nella dashboard delle API, scegli la tua API GraphQL.
2. Nella barra laterale, scegli Impostazioni.
In Modalità di autorizzazione predefinita, scegli la chiave API.
Nella tabella 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 e scegli Elimina.
Scegli Save (Salva) nella parte inferiore della pagina.

CLI

Se non l'hai già fatto, configura il tuo accesso alla AWS CLI. Per ulteriori informazioni, consulta Nozioni di base sulla https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html configurazione.

Crea un oggetto API GraphQL eseguendo il update-graphql-api comando.

Dovrai digitare due parametri per questo particolare comando:

La api-id tua API GraphQL.
La novità name della tua API. Puoi usare la stessaname.
Ilauthentication-type, che saràAPI_KEY.

Nota

Esistono altri parametri Region che devono essere configurati, ma di solito vengono utilizzati per impostazione predefinita i valori di configurazione della CLI.

Un comando di esempio può essere simile al seguente:


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

Autorizzazione AWS_LAMBDA

Puoi implementare la tua logica di autorizzazione API utilizzando una funzione. AWS Lambda Puoi utilizzare una funzione Lambda per l'autorizzatore primario o secondario, ma può esserci una sola funzione di autorizzazione Lambda per API. Quando si utilizzano le funzioni Lambda per l'autorizzazione, vale quanto segue:

Se le modalità di AWS_IAM autorizzazione dell'AWS_LAMBDAAPI sono 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 and 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 tuo 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 richiamate 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 la risposta di un autorizzatore Lambda è inferiore a 1.048.576 byte, AWS AppSync memorizza nella cache la risposta per le richieste successive. Se la risposta dell'autorizzatore Lambda è uguale o superiore a 1.048.576 byte, AWS AppSync non memorizza nella cache la risposta e richiama l'autorizzatore Lambda per ogni richiesta in arrivo. Per ottimizzare le prestazioni e ridurre al minimo i costi di chiamata Lambda, ti consigliamo di limitare le risposte dell'autorizzatore Lambda a 1.048.576 byte. Per impostazione predefinita, la memorizzazione nella cache non è attiva, 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 che la funzione venga chiamata. Queste espressioni regolari vengono utilizzate per convalidare che un token di autorizzazione sia nel 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 AWS AppSync per consentire la chiamata. Questa azione viene eseguita automaticamente nella AWS AppSync console; la AWS AppSync console non rimuove la policy. Per ulteriori informazioni sull'associazione delle policy alle funzioni Lambda, consulta le Resource-based policy nella AWS Lambda Developer Guide.

La funzione Lambda specificata riceverà un evento con la seguente forma:


{
    "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'eventoggetto contiene le intestazioni inviate nella richiesta dal client dell'applicazione a. AWS AppSync

La funzione di autorizzazione deve restituire almeno isAuthorized un valore booleano che indichi 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 "». AWS AppSync DeepDish:Connect

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 forzatamente modificato innull, anche se un valore è stato restituito da un resolver.

Ogni elemento è un ARN di campo completo sotto forma di arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldName o una forma abbreviata di. TypeName.FieldName Il modulo ARN completo deve essere utilizzato quando due API condividono un autorizzatore di funzioni Lambda e potrebbe esserci ambiguità tra i tipi e i campi comuni tra le due API.

resolverContext(Oggetto JSON, opzionale)

Un oggetto JSON visibile come $ctx.identity.resolverContext nei modelli di resolver. Ad esempio, se la seguente struttura viene restituita da un resolver:


{
  "isAuthorized":true
  "resolverContext": {
    "banana":"very yellow",
    "apple":"very green" 
  }
}

Il valore di ctx.identity.resolverContext.apple in resolver templates sarà "». very green L'resolverContextoggetto supporta solo coppie chiave-valore. Le chiavi annidate non sono supportate.

avvertimento

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.

Gli autorizzatori Lambda hanno un timeout standard di 10 secondi, ma potrebbero scadere prima in condizioni di traffico di punta. Ti consigliamo di progettare funzioni da eseguire nel minor tempo possibile (meno di 1 secondo) per scalare le prestazioni della tua API.

Più AWS AppSync API possono condividere una singola funzione Lambda di autenticazione. L'uso di autorizzatori per più account non è consentito.

Quando condividi una funzione di autorizzazione tra più API, tieni presente che i nomi di campo in formato abbreviato (typename.fieldname) possono nascondere inavvertitamente i campi. Per disambiguare un campo indeniedFields, puoi specificare un campo ARN univoco 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

L'esempio seguente descrive una funzione Lambda che dimostra i vari stati di autenticazione e di errore che una funzione Lambda può avere se utilizzata come meccanismo di AWS AppSync autorizzazione:



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 AWS_LAMBDA autorizzazione AWS_IAM e sono abilitate per l'API, procedi come segue: AWS AppSync

Per creare un nuovo token di autorizzazione Lambda, aggiungi prefissi di suffissi and/or casuali alla firma SigV4.
Per recuperare la firma SigV4 originale, aggiorna la funzione Lambda rimuovendo i suffissi dei prefissi casuali dal token di autorizzazione Lambda. and/or 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, procedi come AWS AppSync segue:

Per creare un nuovo token di autorizzazione Lambda, aggiungi prefissi di suffissi and/or 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 suffissi dei and/or prefissi casuali dal token di autorizzazione Lambda. Quindi, usa il token OIDC originale per l'autenticazione.

Autorizzazione AWS_IAM

Questo tipo di autorizzazione impone il processo di AWS firma della versione 4 sull'API GraphQL. È possibile associare policy d'accesso Identity and Access Management (IAM) a questo tipo di autorizzazione. L'applicazione può sfruttare questa associazione utilizzando una chiave di accesso (costituita da un ID della 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:

Puoi YourGraphQLApiId trovarle nella 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.

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 policy IAM corrispondente per un ruolo (che potresti collegare a un pool di identità Amazon Cognito, ad esempio) sarebbe la seguente:

Autorizzazione OPENID_CONNECT

Questo tipo di autorizzazione applica i token OpenID connect (OIDC) forniti da un servizio. OIDC-compliant 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 viene aggiunto /.well-known/openid-configuration all'URL dell'emittente e individua la configurazione OpenID https://auth.example.com/.well-known/openid-configuration secondo la specifica OpenID Connect Discovery. https://openid.net/specs/openid-connect-discovery-1_0.html Il servizio prevede di recuperare un documento JSON conforme a RFC5785 in 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 il JWKS contenga i 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
HS 256
HS384
HS 512
ES 256
ES 384
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 il claim richiedendo che corrisponda clientId al azp claim aud o nel token.

Per convalidare più ID client, usa l'operatore pipeline («|») che è un «o» nell'espressione regolare. Ad esempio, se l'applicazione OIDC ha quattro client con ID client come 0A1S2D, 1F4G9H, 1J6L4B, 6GS5MG, per convalidare solo i primi tre ID client, è necessario inserire 1F4G9H|1J6L4B|6GS5MG 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 l'autorizzazione OPENID_CONNECT, salta questa fase di convalida dell'URL dell'emittente. AWS AppSync

Autorizzazione AMAZON_COGNITO_USER_POOLS

Questo tipo di autorizzazione applica i token OIDC forniti dai pool di utenti di Amazon Cognito. La tua applicazione può sfruttare gli utenti e i gruppi dei tuoi pool di utenti e dei pool di utenti di un altro AWS account e associarli ai campi GraphQL per il controllo degli accessi.

Quando utilizzi 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"])
}
...

Nota che puoi omettere la direttiva @aws_auth se vuoi passare in modo automatico a una strategia di concessione o rifiuto specifica per l'accesso. Puoi specificare la strategia di concessione o rifiuto nella configurazione del pool di utenti quando crei l'API GraphQL tramite la console o il comando dell'interfaccia a riga di comando seguente:


$ 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 si aggiungono modalità di autorizzazione aggiuntive, è possibile configurare direttamente l'impostazione di autorizzazione a livello di API AWS AppSync GraphQL (ovvero, il authenticationType campo che è possibile configurare direttamente sull'GraphqlApioggetto) 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 API_KEY l'autorizzazione si utilizzerebbe il tipo @aws_api_key definitions/fields 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 nell'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 configurarlo 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
}
...

Fine-grained controllo 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.

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 familiarità con i modelli di mappatura in AWS AppSync, potresti voler esaminare il riferimento al modello di mappatura Resolver e il riferimento al modello di mappatura Resolver per DynamoDB. Resolver Mapping Template Reference for DynamoDB

Nel seguente esempio di utilizzo di DynamoDB, supponiamo di utilizzare lo schema del 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.

Four-step flusso di lavoro che mostra il recupero dei token, l'invio di richieste, il controllo condizionale e l'esecuzione dell'operazione.

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'UpdateItemoperazione 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 UpdateItem chiamata 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 del codice 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 pereditPost, che aggiorna il contenuto del post del 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é unUpdateItem, 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 del blog (ad esempio un indice attivo). 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 politiche di accesso di Identity and Access Management (IAM). Se si utilizza un ruolo esistente, è necessario aggiungere una Trust Policy per AWS AppSync assumere il ruolo. La relazione di attendibilità apparirà come segue:

È 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 per te. 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.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Utilizzo delle variabili di ambiente

Casi d'uso del controllo degli accessi per proteggere richieste e risposte

Configurazione dell'autorizzazione e dell'autenticazione per proteggere le API GraphQL

Tipi di autorizzazione

Autorizzazione API_KEY

Nota

Autorizzazione AWS_LAMBDA

Nota

avvertimento

Nota

Importante

Nota

Eludere le limitazioni di autorizzazione dei token SIGv4 e OIDC

Autorizzazione AWS_IAM

Autorizzazione OPENID_CONNECT

Autorizzazione AMAZON_COGNITO_USER_POOLS

Utilizzo di modalità di autorizzazione aggiuntive

Fine-grained controllo degli accessi

Filtraggio delle informazioni

Accesso origine dati