Tipi di autorizzazione API_ autorizzazione KEY AWS_ autorizzazione LAMBDA AWS_ IAM autorizzazione OPENID_ autorizzazione CONNECT AMAZON_ _ _ autorizzazione COGNITO USER POOLS Utilizzo di modalità di autorizzazione aggiuntive Controllo granulare degli accessi Filtraggio delle informazioni Accesso origine dati

Configurazione dell'autorizzazione e dell'autenticazione per proteggere GraphQL APIs

AWS AppSync offre i seguenti tipi di autorizzazione per proteggere GraphQLAPIs: API keys, Lambda, IAM OpenID Connect e Cognito User Pools. Ogni opzione offre un metodo di sicurezza diverso:

APIAutorizzazione con chiave: controlla la limitazione per i non autenticatiAPIs, fornendo una semplice opzione di sicurezza.
Autorizzazione Lambda: abilita la logica di autorizzazione personalizzata, spiegando in dettaglio gli input e gli output delle funzioni.
IAMAutorizzazione: utilizza il processo AWS di firma della versione 4 della firma, che consente un controllo granulare degli accessi tramite policy. IAM
Autorizzazione OpenID Connect: si integra con i servizi conformi a OIDC -compliant per l'autenticazione degli utenti.
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 AWS AppSync GraphQLAPI. È possibile specificare il tipo di autorizzazione da utilizzare specificando uno dei seguenti valori del tipo di autorizzazione nella chiamata or: AWS AppSync API CLI

API_KEY

Per usare API le chiavi.
AWS_LAMBDA

Per usare una AWS Lambda funzione.
AWS_IAM

Per utilizzare i permessi AWS Identity and Access Management (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 ulteriori modalità di autorizzazione tramite la consoleCLI, il e AWS CloudFormation. Per le modalità di autorizzazione aggiuntive, AWS AppSync fornisce un tipo di autorizzazione che accetta i valori sopra elencati (ovvero API_KEYAWS_LAMBDA,AWS_IAM,OPENID_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 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.

API_ autorizzazione KEY

I non autenticati APIs richiedono una limitazione più rigorosa di quelli autenticati. APIs Un modo per controllare la limitazione per gli endpoint GraphQL non autenticati è l'uso di chiavi. API Una API chiave è un valore codificato nell'applicazione che viene generato dal AWS AppSync servizio quando si crea un endpoint GraphQL non autenticato. È possibile ruotare i API tasti dalla console, dal o dal riferimento. CLI AWS AppSync API

Console

Accedi AWS Management Console e apri la AppSyncconsole.
1. Nella APIsdashboard, scegli il tuo GraphQLAPI.
2. Nella barra laterale, scegli Impostazioni.
In Modalità di autorizzazione predefinita, scegli APIchiave.
Nella tabella delle APIchiavi, scegli Aggiungi API chiave.

Una nuova API chiave verrà generata nella tabella.
1. Per eliminare una vecchia API chiave, selezionate la API chiave nella tabella, quindi scegliete Elimina.
Scegli Save (Salva) nella parte inferiore della pagina.

CLI

Se non l'hai già fatto, configura il tuo accesso a AWS CLI. Per ulteriori informazioni, consulta Nozioni di base sulla configurazione.

Crea un API oggetto GraphQL eseguendo il update-graphql-apicomando.

Dovrai digitare due parametri per questo particolare comando:

Il api-id tuo GraphQLAPI.
Il nuovo name dei tuoi. API Puoi usare lo stessoname.
Ilauthentication-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 CLI di configurazione.

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 inCLI. Ecco un esempio inJSON:


{
    "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"
    }
}

APIle chiavi sono configurabili per un massimo di 365 giorni ed è possibile estendere una data di scadenza esistente fino ad altri 365 giorni a partire da quel giorno. APILe chiavi sono consigliate per scopi di sviluppo o casi d'uso in cui è sicuro esporre un pubblico. API

Sul client, la API chiave è specificata dall'x-api-keyintestazione.

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_ autorizzazione LAMBDA

È possibile implementare la propria logica di API autorizzazione utilizzando una AWS Lambda funzione. È possibile utilizzare una funzione Lambda per l'autorizzatore principale o secondario, ma può esserci solo una funzione di autorizzazione Lambda per ogni. API Quando si utilizzano le funzioni Lambda per l'autorizzazione, si applica quanto segue:

Se API ha le modalità di AWS_IAM autorizzazione AWS_LAMBDA e abilitate, la firma SigV4 non può essere utilizzata come token di autorizzazione. AWS_LAMBDA
Se API ha le modalità di OPENID_CONNECT autorizzazione AWS_LAMBDA e o la modalità di AMAZON_COGNITO_USER_POOLS autorizzazione abilitate, il OIDC token non può essere utilizzato come token di AWS_LAMBDA autorizzazione. Nota che il OIDC token 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'APIID e al token di autenticazione. Per impostazione predefinita, la memorizzazione nella cache non è attivata, ma può essere abilitata a API livello o impostando il ttlOverride valore nel valore restituito da una funzione.

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 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'eventoggetto 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:

isAuthorized(booleano, obbligatorio)

Un valore booleano che indica se il valore in authorizationToken è autorizzato a effettuare chiamate a GraphQL. API

Se questo valore è vero, l'esecuzione di GraphQL continuaAPI. Se questo valore è falso, UnauthorizedException viene generato un

deniedFields(elenco di stringhe, opzionale)

Un elenco dei quali viene modificato forzatamente innull, anche se un valore è stato restituito da un resolver.

Ogni elemento è un campo completamente qualificato in forma arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldName o ARN in forma abbreviata di. TypeName.FieldName Il ARN modulo completo deve essere usato quando due persone APIs condividono un autorizzatore di funzioni Lambda e potrebbero esserci ambiguità tra i tipi e i campi comuni tra i due. APIs

resolverContext(JSONOggetto, opzionale)

Un JSON oggetto 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'resolverContextoggetto supporta solo coppie chiave-valore. Le chiavi annidate non sono supportate.

avvertimento

La dimensione totale di questo JSON oggetto 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, API viene utilizzato il valore di. Se è 0, la risposta non viene memorizzata nella cache.

Gli autorizzatori Lambda hanno un timeout di 10 secondi. Ti consigliamo di progettare funzioni da eseguire nel più breve tempo possibile per scalare le prestazioni del tuo. 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ù personeAPIs, tenete presente che i nomi di campo in formato breve (typename.fieldname) possono inavvertitamente nascondere dei campi. Per disambiguare un campo indeniedFields, puoi specificare un campo non ambiguo sotto forma di. ARN 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 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 i limiti di autorizzazione di SigV4 e token OIDC

I seguenti metodi possono essere utilizzati per aggirare il problema dell'impossibilità di utilizzare la firma o il token SigV4 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 's AWS AppSync'API, procedi come segue:

Per creare un nuovo token di autorizzazione Lambda, aggiungi suffissi e/o prefissi casuali alla firma SigV4.
Per recuperare la firma SigV4 originale, aggiorna la funzione Lambda rimuovendo i prefissi e/o i suffissi casuali dal token di autorizzazione Lambda. Quindi, usa la firma SigV4 originale per l'autenticazione.

Se desideri utilizzare il OIDC token come token di autorizzazione Lambda quando la modalità di OPENID_CONNECT autorizzazione o le modalità di AWS_LAMBDA autorizzazione AMAZON_COGNITO_USER_POOLS e sono abilitateAPI, AWS AppSync procedi come segue:

Per creare un nuovo token di autorizzazione Lambda, aggiungi suffissi e/o prefissi casuali al token. OIDC Il token di autorizzazione Lambda non deve contenere un prefisso dello schema Bearer.
Per recuperare il OIDC token originale, aggiorna la funzione Lambda rimuovendo i prefissi e/o i suffissi casuali dal token di autorizzazione Lambda. Quindi, usa il token originale per l'autenticazione. OIDC

AWS_ IAM autorizzazione

Questo tipo di autorizzazione applica il processo di AWS firma della versione 4 della firma su GraphQLAPI. È possibile associare le policy di accesso Identity and Access Management (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:


{
   "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 di API elenco principale della AppSync console, direttamente sotto il nome del tuo. API In alternativa puoi recuperarlo con: CLI 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.


{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-2>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/<Field-1>"
         ]
     }
   ]
}

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


{
    "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_ autorizzazione CONNECT

Questo tipo di autorizzazione applica i token OpenID connect OIDC () forniti da OIDC un servizio conforme a. L'applicazione può sfruttare gli utenti e i privilegi definiti dal provider per il controllo degli accessi. OIDC

Un emittente URL è l'unico valore di configurazione richiesto fornito a AWS AppSync (ad esempio,). https://auth.example.com Questo URL deve essere indirizzabile su. HTTPS AWS AppSync aggiunge /.well-known/openid-configuration all'emittente URL e individua la configurazione OpenID secondo la specifica OpenID Connect https://auth.example.com/.well-known/openid-configuration Discovery. A questo punto si aspetta di recuperare un documento conforme. RFC5785JSONURL Questo JSON documento deve contenere una jwks_uri chiave che punti al documento JSON Web Key Set (JWKS) con le chiavi di firma. AWS AppSync richiede che JWKS contenga JSON i campi di kty ekid.

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

Ti consigliamo di utilizzare gli RSA algoritmi. 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 fornire TTL valori per l'ora di emissione (iatTTL) e l'ora di autenticazione (authTTL) nella configurazione di OpenID Connect per una convalida aggiuntiva. 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'azpaffermazione aud o nel token.

Per convalidare più client, IDs usa l'operatore pipeline («|») che è un «o» nell'espressione regolare. Ad esempio, se l'OIDCapplicazione ha quattro client con client IDs come 0A1S2D, 1F4G9H, 1J6L4B, 6, per convalidare solo i primi tre client, è necessario inserire 1F4G9H|1J6L4B|6 GS5MG nel campo ID client. IDs GS5MG

AMAZON_ _ _ autorizzazione COGNITO USER POOLS

Questo tipo di autorizzazione applica i OIDC token 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 JWT token 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 GraphQL API tramite la console o tramite il seguente CLI comando:


$ 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 API livello di AWS AppSync GraphQL (ovvero, il authenticationType campo che puoi 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 del API livello.

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 su AWS AppSync GraphQLAPI. 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 configurare come modalità di autorizzazione aggiuntiva su AWS AppSync GraphQL API 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.

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 di Resolver AWS AppSync, puoi consultare il riferimento al modello di mappatura Resolver e il riferimento al modello di mappatura Resolver 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.

Diagram showing authentication flow with Cognito User Pools, AppSync, mapping template, and database. (AI generated)

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 foreditPost, 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é unoUpdateItem, 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). 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:


{
    "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 IAM console per creare un ruolo all'esterno della AWS AppSync console, le autorizzazioni non verranno automaticamente limitate a una risorsa e dovresti 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 in AWS AppSync

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

Configurazione dell'autorizzazione e dell'autenticazione per proteggere GraphQL APIs

Tipi di autorizzazione

API_ autorizzazione KEY

Nota

AWS_ autorizzazione LAMBDA

avvertimento

Nota

Importante

Nota

Eludere i limiti di autorizzazione di SigV4 e token OIDC

AWS_ IAM autorizzazione

OPENID_ autorizzazione CONNECT

AMAZON_ _ _ autorizzazione COGNITO USER POOLS

Utilizzo di modalità di autorizzazione aggiuntive

Controllo granulare degli accessi

Filtraggio delle informazioni

Accesso origine dati