Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfiguration der Autorisierung und Authentifizierung zur Sicherung Ihrer GraphQL-APIs

AWS AppSync bietet die folgenden Autorisierungstypen zum Sichern von GraphQL-APIs: API-Schlüssel, Lambda-, IAM-, OpenID Connect- und Cognito-Benutzerpools. Jede Option bietet eine andere Sicherheitsmethode:

Arten der Autorisierung

Es gibt fünf Möglichkeiten, Anwendungen für die Interaktion mit Ihrer AWS AppSync GraphQL-API zu autorisieren. Sie geben an, welchen Autorisierungstyp Sie verwenden, indem Sie in Ihrem AWS AppSync API- oder CLI-Aufruf einen der folgenden Werte für den Autorisierungstyp angeben:

Diese grundlegenden Autorisierungstypen funktionieren für die meisten Entwickler. Für fortgeschrittenere Anwendungsfälle können Sie zusätzliche Autorisierungsmodi über die Konsole, die CLI und AWS CloudFormation hinzufügen. AWS AppSync Stellt für zusätzliche Autorisierungsmodi einen Autorisierungstyp bereit, der die oben aufgeführten Werte verwendet (d. API_KEY h.AWS_LAMBDA,AWS_IAM,OPENID_CONNECT, undAMAZON_COGNITO_USER_POOLS).

Wenn Sie oder AWS_IAM als Haupt AWS_LAMBDA - oder Standardautorisierungstyp angeben, können Sie ihn nicht erneut als einen der zusätzlichen Autorisierungsmodi angeben. API_KEY Ebenso können Sie die zusätzlichen Autorisierungsmodi nicht duplizieren API_KEY AWS_LAMBDA oder AWS_IAM innerhalb der zusätzlichen Autorisierungsmodi verwenden. Sie können mehrere Amazon Cognito-Benutzerpools und OpenID Connect-Anbieter verwenden. Sie können jedoch keine doppelten Amazon Cognito-Benutzerpools oder OpenID Connect-Anbieter zwischen dem Standardautorisierungsmodus und einem der zusätzlichen Autorisierungsmodi verwenden. Sie können mithilfe des entsprechenden regulären Konfigurationsausdrucks verschiedene Clients für Ihren Amazon Cognito-Benutzerpool oder OpenID Connect-Anbieter angeben.

Wenn Sie Änderungen an Ihrer API-Konfiguration speichern, AWS AppSync beginnt die Änderungen zu übertragen. Stellt AWS AppSync weiterhin Ihre Inhalte aus der vorherigen Konfiguration bereit, bis Ihre Konfigurationsänderung weitergegeben wird. Nachdem Ihre Konfigurationsänderung weitergegeben wurde, beginnt AWS AppSync sofort die Bereitstellung Ihrer Inhalte auf der Grundlage der neuen Konfiguration. Während AWS AppSync der Propagierung Ihrer Änderungen für eine API können wir anhand der vorherigen oder der neuen Konfiguration nicht feststellen, ob die API Ihre Inhalte bereitstellt.

API_KEY-Autorisierung

Nicht authentifizierte APIs benötigen eine strengere Ablehnung als authentifizierte APIs. Eine Möglichkeit zur Kontrolle der Ablehnung für nicht authentifizierte GraphQL-Endpunkte ist die Verwendung von API-Schlüsseln. Ein API-Schlüssel ist ein hartcodierter Wert in Ihrer Anwendung, der vom AWS AppSync-Service beim Erstellen eines nicht authentifizierten GraphQL-Endpunktes generiert wird. Sie können API-Schlüssel von der Konsole, von der CLI oder von der AWS AppSync API-Referenz aus rotieren.

Console

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AppSync Konsole.

   1. Wählen Sie im API-Dashboard Ihre GraphQL-API aus.

   2. Wählen Sie in der Seitenleiste Einstellungen aus.

2. Wählen Sie unter Standardautorisierungsmodus die Option API-Schlüssel aus.

3. Wählen Sie in der Tabelle mit den API-Schlüsseln die Option API-Schlüssel hinzufügen aus.

   In der Tabelle wird ein neuer API-Schlüssel generiert.

   1. Um einen alten API-Schlüssel zu löschen, wählen Sie den API-Schlüssel in der Tabelle aus und klicken Sie dann auf Löschen.

4. Wählen Sie unten auf der Seite die Option Save aus.

CLI

1. Falls Sie dies noch nicht getan haben, konfigurieren Sie Ihren Zugriff auf die AWS CLI. Weitere Informationen finden Sie unter Grundlagen der Konfiguration.

2. Erstellen Sie ein GraphQL-API-Objekt, indem Sie den update-graphql-api Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie zwei Parameter eingeben:

   1. Die api-id Ihrer GraphQL-API.

   2. Das Neue name Ihrer API. Sie können dasselbe verwendenname.

   3. Dasauthentication-type, was sein wirdAPI_KEY.

   Anmerkung

   Es gibt noch andere Parameter, Region die konfiguriert werden müssen, aber normalerweise werden standardmäßig Ihre CLI-Konfigurationswerte verwendet.

   Ein Beispielbefehl könnte so aussehen:

   aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ist ein Beispiel 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"
       }
   }

API-Schlüssel sind für bis zu 365 Tage konfigurierbar und Sie können diese ab dem Ablaufdatum für bis zu weitere 365 Tage verlängern. API-Schlüssel werden für Entwicklungszwecke oder Anwendungsfälle empfohlen, bei denen die Bereitstellung einer öffentliche API sicher ist.

Auf dem Client ist der API-Schlüssel mit dem Header x-api-key angegeben.

Wenn z. B. der Wert Ihres API_KEY 'ABC123' lautet, können Sie über curl eine GraphQL-Abfrage senden. Gehen Sie dazu wie folgt vor:

$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

AWS_LAMBDA-Autorisierung

Sie können Ihre eigene API-Autorisierungslogik mithilfe einer Funktion implementieren. AWS Lambda Sie können eine Lambda-Funktion entweder für Ihren primären oder sekundären Autorisierer verwenden, es kann jedoch nur eine Lambda-Autorisierungsfunktion pro API geben. Wenn Sie Lambda-Funktionen für die Autorisierung verwenden, gilt Folgendes:

Wenn Ihr Autorisierungstoken beispielsweise lautet'ABC123', können Sie eine GraphQL-Abfrage wie folgt über curl senden:

$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query":
         "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
      

Lambda-Funktionen werden vor jeder Abfrage oder Mutation aufgerufen. Der Rückgabewert kann basierend auf der API-ID und dem Authentifizierungstoken zwischengespeichert werden. Wenn eine Lambda-Autorisierungsantwort weniger als 1.048.576 Byte umfasst, AWS AppSync wird die Antwort für nachfolgende Anfragen zwischengespeichert. Wenn die Antwort des Lambda-Autorisierers 1.048.576 Byte oder mehr beträgt, wird die Antwort AWS AppSync nicht zwischengespeichert und der Lambda-Autorisierer wird für jede eingehende Anfrage aufgerufen. Um die Leistung zu optimieren und die Kosten für Lambda-Aufrufe zu minimieren, empfehlen wir, dass Sie Ihre Lambda-Authorizer-Antworten auf 1.048.576 Byte beschränken. Standardmäßig ist das Caching nicht aktiviert, aber dies kann auf API-Ebene oder durch Festlegen des Werts im Rückgabewert einer Funktion aktiviert werden. ttlOverride

Bei Bedarf kann ein regulärer Ausdruck angegeben werden, der Autorisierungstoken validiert, bevor die Funktion aufgerufen wird. Diese regulären Ausdrücke werden verwendet, um zu überprüfen, ob ein Autorisierungstoken das richtige Format hat, bevor Ihre Funktion aufgerufen wird. Jede Anfrage, die ein Token verwendet, das nicht mit diesem regulären Ausdruck übereinstimmt, wird automatisch abgelehnt.

Lambda-Funktionen, die für die Autorisierung verwendet werden, benötigen eine Prinzipalrichtlinieappsync.amazonaws.com, die auf sie angewendet werden muss, um sie aufrufen AWS AppSync zu können. Diese Aktion wird automatisch in der AWS AppSync Konsole ausgeführt. Die AWS AppSync Konsole entfernt die Richtlinie nicht. Weitere Informationen zum Anhängen von Richtlinien an Lambda-Funktionen finden Sie unter Resource-based Richtlinien im AWS Lambda Entwicklerhandbuch.

Die von Ihnen angegebene Lambda-Funktion erhält ein Ereignis mit der folgenden Form:

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

Das event Objekt enthält die Header, die in der Anfrage vom Anwendungsclient an gesendet wurden. AWS AppSync

Die Autorisierungsfunktion muss mindestens einen booleschen Wert zurückgebenisAuthorized, der angibt, ob die Anforderung autorisiert ist. AWS AppSync erkennt die folgenden Schlüssel, die von den Lambda-Autorisierungsfunktionen zurückgegeben werden:

So fügen Sie eine Lambda-Funktion als Standardautorisierungsmodus hinzu in: AWS AppSync

Console

1. Melden Sie sich in der AWS AppSync Konsole an und navigieren Sie zu der API, die Sie aktualisieren möchten.

2. Navigieren Sie zur Einstellungsseite für Ihre API.

   Ändern Sie die API-Level Autorisierung in AWS Lambda.

3. Wählen Sie den AWS-Region und den Lambda-ARN, für den API-Aufrufe autorisiert werden sollen.

   Anmerkung

   Die entsprechende Prinzipalrichtlinie wird automatisch hinzugefügt, sodass Sie Ihre AWS AppSync Lambda-Funktion aufrufen können.

4. Legen Sie optional die TTL für die Antwort und den regulären Ausdruck für die Token-Validierung fest.

AWS CLI

1. Hängen Sie die folgende Richtlinie an die verwendete Lambda-Funktion an:

   aws lambda add-permission --function-name "my-function" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text 

   Wichtig

   Wenn Sie möchten, dass die Richtlinie der Funktion an eine einzelne GraphQL-API gebunden ist, können Sie diesen Befehl ausführen:

   aws lambda add-permission --function-name “my-function” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “<my AppSync API ARN>” --output text

2. Aktualisieren Sie Ihre AWS AppSync API, um den angegebenen ARN der Lambda-Funktion als Autorisierer zu verwenden:

   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"

   Anmerkung

   Sie können auch andere Konfigurationsoptionen wie den regulären Token-Ausdruck einbeziehen.

Das folgende Beispiel beschreibt eine Lambda-Funktion, die die verschiedenen Authentifizierungs- und Fehlerzustände demonstriert, die eine Lambda-Funktion annehmen kann, wenn sie als AWS AppSync Autorisierungsmechanismus verwendet wird:

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

Umgehung der SigV4- und OIDC-Token-Autorisierungsbeschränkungen

Die folgenden Methoden können verwendet werden, um das Problem zu umgehen, dass Sie Ihre SigV4-Signatur oder Ihr OIDC-Token nicht als Lambda-Autorisierungstoken verwenden können, wenn bestimmte Autorisierungsmodi aktiviert sind.

Wenn Sie die SigV4-Signatur als Lambda-Autorisierungstoken verwenden möchten, wenn die AWS_LAMBDA Autorisierungsmodi AWS_IAM und für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor:

Wenn Sie das OIDC-Token als Lambda-Autorisierungstoken verwenden möchten, wenn der Autorisierungsmodus oder die OPENID_CONNECT AWS_LAMBDA Autorisierungsmodi AMAZON_COGNITO_USER_POOLS und für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor:

AWS_IAM-Autorisierung

Dieser Autorisierungstyp erzwingt den AWS Signaturprozess der Version 4 auf der GraphQL-API. Sie können vordefinierte Zugriffsrichtlinien für Identity and Access Management (IAM) mit diesem Autorisierungstyp verknüpfen. Ihre Anwendung kann diese Verknüpfung nutzen, indem sie einen Zugriffsschlüssel (der aus einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel besteht) oder indem kurzlebige, temporäre Anmeldeinformationen verwendet werden, die von Amazon Cognito Federated Identities bereitgestellt werden.

Wenn Sie eine Rolle möchten, die Zugriff darauf hat, alle Datenoperationen durchzuführen:

JSON

{
   "Version":"2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*"
         ]
      }
   ]
}

Sie finden sie auf YourGraphQLApiId der API-Hauptseite in der AppSync Konsole direkt unter dem Namen Ihrer API. Alternativ können Sie sie mit der CLI abrufen: aws appsync list-graphql-apis.

Wenn Sie den Zugriff auf nur bestimmte GraphQL-Operationen einschränken möchten, können Sie dies für die Stammfelder Query, Mutation und Subscription tun.

JSON

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

Angenommen, Sie haben das folgende Schema und Sie möchten den Zugriff zum Abrufen aller Beiträge beschränken:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}

Die entsprechende IAM-Richtlinie für eine Rolle (die Sie beispielsweise an einen Amazon Cognito-Identitätspool anhängen könnten) würde wie folgt aussehen:

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-Autorisierung

Dieser Autorisierungstyp erzwingt OpenID Connect (OIDC) -Token, die von einem Dienst bereitgestellt werden. OIDC-compliant Ihre Anwendung kann Benutzer und Berechtigungen nutzen, die von Ihrem OIDC-Anbieter zur Kontrolle des Zugriffs definiert wurden.

Eine Aussteller-URL ist der einzige erforderliche Konfigurationswert, den Sie AWS AppSync bereitstellen, (z. B. https://auth.example.com). Diese URL muss über HTTPS adressierbar sein. AWS AppSync wird /.well-known/openid-configuration an die Aussteller-URL angehängt und ermittelt die OpenID-Konfiguration https://auth.example.com/.well-known/openid-configuration gemäß der OpenID Connect Discovery-Spezifikation. https://openid.net/specs/openid-connect-discovery-1_0.html Es erwartet, ein RFC5785-konformes JSON-Dokument unter dieser URL abzurufen. Dieses JSON-Dokument muss einen jwks_uri Schlüssel enthalten, der auf das JWKS-Dokument (JSON Web Key Set) mit den Signaturschlüsseln verweist. AWS AppSync erfordert, dass das JWKS die JSON-Felder und enthält. kty kid

AWS AppSync unterstützt eine Vielzahl von Signaturalgorithmen.

Wir empfehlen Ihnen, die RSA-Algorithmen zu verwenden. Token, die vom Anbieter ausgestellt wurden, müssen die Uhrzeit, zu der das Token ausgestellt wurde (iat), und den Zeitpunkt, zu dem es authentifiziert wurde (auth_time), enthalten. Sie können TTL-Werte für die ausgestellte Zeit (iatTTL) und die Authentifizierungszeit (authTTL) in Ihrer OpenID Connect-Konfiguration zur zusätzlichen Validierung bereitstellen. Wenn Ihr Anbieter mehrere Anwendungen autorisiert, können Sie auch einen regulären Ausdruck (clientId) angeben, der von der Client-ID zur Autorisierung verwendet wird. Wenn der in Ihrer OpenID Connect-Konfiguration vorhanden clientId ist, AWS AppSync validiert er den Anspruch, indem er verlangt, dass er entweder mit dem aud oder dem azp Anspruch im Token übereinstimmt. clientId

Um mehrere Client-IDs zu validieren, verwenden Sie den Pipeline-Operator („|“), der ein „oder“ in regulären Ausdrücken ist. Wenn Ihre OIDC-Anwendung beispielsweise vier Clients mit Client-IDs wie 0A1S2D, 1F4G9H, 1J6L4B, 6GS5MG hat, würden Sie zur Überprüfung nur der ersten drei Client-IDs 1F4G9H|1J6L4B|6GS5MG in das Client-ID-Feld eingeben.

Wenn eine API mit mehreren Autorisierungstypen konfiguriert ist, AWS AppSync validiert sie den im JWT-Token vorhandenen Aussteller (ISS-Anspruch) anhand der Anforderungsheader, indem er ihn mit der in der API-Konfiguration angegebenen Aussteller-URL vergleicht. Wenn eine API jedoch nur mit der OPENID_CONNECT-Autorisierung konfiguriert ist, wird dieser Schritt zur Überprüfung der Aussteller-URL übersprungen. AWS AppSync

AMAZON_COGNITO_USER_POOLS-Autorisierung

Dieser Autorisierungstyp erzwingt OIDC-Token, die von Amazon Cognito-Benutzerpools bereitgestellt werden. Ihre Anwendung kann die Benutzer und Gruppen in Ihren Benutzerpools und Benutzerpools von einem anderen AWS Konto nutzen und diese GraphQL-Feldern zur Zugriffskontrolle zuordnen.

Wenn Sie Amazon Cognito-Benutzerpools verwenden, können Sie Gruppen erstellen, denen Benutzer angehören. Diese Informationen sind in einem JWT-Token kodiert, an das Ihre Anwendung beim Senden von GraphQL-Operationen AWS AppSync in einem Autorisierungsheader sendet. Sie können GraphQL-Richtlinien für das Schema verwenden, um zu steuern, welche Gruppen welche Resolver auf einem Feld aufrufen können, wodurch Ihren Kunden mehr kontrollierter Zugriff gewährt wird.

Angenommen, Sie haben das folgende GraphQL-Schema:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}
...

Wenn Sie zwei Gruppen in Amazon Cognito-Benutzerpools haben — Blogger und Leser — und Sie die Anzahl der Leser einschränken möchten, sodass sie keine neuen Einträge hinzufügen können, sollte Ihr Schema wie folgt aussehen:

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

Beachten Sie, dass Sie die @aws_auth-Anweisung bei Bedarf weglassen können, wenn Sie standardmäßig eine spezifische Strategie der Zugriffsgewährung oder -verweigerung wünschen. Sie können die Strategie der Zugriffsgewährung oder -verweigerung in der Benutzerpool-Konfiguration beim Erstellen Ihrer GraphQL-API über die Konsole oder über den folgenden CLI-Befehl spezifizieren:

$ 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"}'

Verwenden zusätzlicher Autorisierungsmodi

Wenn Sie zusätzliche Autorisierungsmodi hinzufügen, können Sie die Autorisierungseinstellung direkt auf der AWS AppSync GraphQL-API-Ebene konfigurieren (d. h. das authenticationType Feld, das Sie direkt für das GraphqlApi Objekt konfigurieren können) und sie dient als Standard für das Schema. Dies bedeutet, dass jeder Typ, der keine bestimmte Richtlinie hat, die Autorisierungseinstellung auf API-Ebene übergeben muss.

Auf Schemaebene können Sie zusätzliche Autorisierungsmodi mithilfe von Anweisungen für das Schema angeben. Sie können Autorisierungsmodi für einzelne Felder im Schema angeben. Für die API_KEY Autorisierung würden Sie beispielsweise einen Schemaobjekttyp definitions/fields verwenden@aws_api_key. Die folgenden Anweisungen werden für Schemafelder und Objekttypdefinitionen unterstützt:

Sie können die Richtlinie @aws_auth nicht zusammen mit zusätzlichen Autorisierungsmodi verwenden. @aws_auth funktioniert nur im Kontext der AMAZON_COGNITO_USER_POOLS-Autorisierung ohne zusätzliche Autorisierungsmodi. Sie können jedoch die @aws_cognito_user_pools-Anweisung anstelle der @aws_auth-Richtlinie verwenden, indem Sie dieselben Argumente verwenden. Der Hauptunterschied zwischen den beiden besteht darin, dass Sie für jede Feld- und Objekttypdefinition @aws_cognito_user_pools angeben können.

Um zu verstehen, wie die zusätzlichen Autorisierungsmodi funktionieren und wie sie in einem Schema angegeben werden können, sehen wir uns das folgende Schema an:

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!
}
...

Gehen Sie für dieses Schema davon aus, dass AWS_IAM dies der Standardautorisierungstyp in der AWS AppSync GraphQL-API ist. Dies bedeutet, dass Felder, die keine Richtlinie haben, mit AWS_IAM geschützt werden. Dies ist beispielsweise der Fall für das Feld getPost des Typs Query. Mit Schemarichtlinien können Sie mehr als einen Autorisierungsmodus verwenden. Sie können beispielsweise einen zusätzlichen Autorisierungsmodus in der AWS AppSync GraphQL-API API_KEY konfiguriert haben, und Sie können ein Feld mithilfe der @aws_api_key Direktive markieren (zum Beispiel getAllPosts in diesem Beispiel). Richtlinien funktionieren auf Feldebene, sodass Sie API_KEY auch Zugriff auf den Typ Post gewähren müssen. Sie können dies entweder tun, indem Sie jedes Feld des Typs Post mit einer Richtlinie markieren oder den Typ Post mit der Richtlinie @aws_api_key markieren.

Um den Zugriff auf Felder des Typs Post weiter einzuschränken, können Sie Anweisungen für einzelne Felder des Typs Post verwenden, wie im Folgenden gezeigt.

Sie können beispielsweise ein restrictedContent-Feld zum Typ Post hinzufügen und den Zugriff darauf mithilfe der Richtlinie @aws_iam einschränken. AWS_IAM-authentifizierte Anfragen könnten auf restrictedContent zugreifen, API_KEY-Anfragen wären dazu jedoch nicht fähig.

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 Zugriffskontrolle

Die vorstehenden Informationen zeigen, wie Sie den Zugriff auf bestimmte GraphQL-Felder beschränken oder gewähren. Wenn Sie Zugriffskontrollen für die Daten basierend auf bestimmten Bedingungen festlegen möchten (z. B. basierend auf dem Benutzer, der einen Aufruf ausführt, oder ob der Benutzer Eigentümer der Daten ist), können Sie dazu Zuweisungsvorlagen in Ihren Resolvern verwenden. Sie können auch eine komplexere Geschäftslogik durchführen, die wir in Filtern von Informationen beschreiben.

In diesem Abschnitt wird gezeigt, wie Sie mithilfe einer DynamoDB-Resolver-Mapping-Vorlage Zugriffskontrollen für Ihre Daten einrichten.

Bevor Sie fortfahren, sollten Sie die Referenz zur Resolver-Mapping-Vorlage und die Resolver-Mapping-Vorlagenreferenz für DynamoDB lesen AWS AppSync, falls Sie mit Mapping-Vorlagen unter nicht vertraut sind. Resolver Mapping Template Reference for DynamoDB

Im folgenden Beispiel, in dem DynamoDB verwendet wird, nehmen wir an, Sie verwenden das vorherige Schema für Blogbeiträge, und nur Benutzer, die einen Beitrag erstellt haben, dürfen ihn bearbeiten. Im Auswertungsverfahren würde der Benutzer dann z. B. mithilfe von Amazon Cognito-Benutzerpools Anmeldeinformationen in seiner Anwendung erhalten und anschließend diese Anmeldeinformationen als Teil einer GraphQL-Operation weiterleiten. Die Zuweisungsvorlage wird dann einen Wert aus den Anmeldeinformationen (z. B. den Benutzernamen) in einer bedingten Anweisung ersetzen, die anschließend mit einem Wert in Ihrer Datenbank verglichen wird.

Um diese Funktionalität zu erhalten, fügen Sie ein GraphQL-Feld von editPost folgendermaßen hinzu:

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!
}
...

Die Resolver-Zuweisungsvorlage für editPost (siehe Beispiel am Ende dieses Abschnitts) muss einen logischen Abgleich Ihres Datenspeichers durchführen, damit nur der Benutzer, der einen Beitrag erstellt hat, diesen auch bearbeiten kann. Da es sich um einen Bearbeitungsvorgang handelt, entspricht er einem UpdateItem in DynamoDB. Sie können vor der Durchführung der Aktion eine bedingte Prüfung mithilfe von Kontext, der zur Benutzeridentitätsvalidierung weitergeleitet wurde, vornehmen. Dieser wird in einem Identity-Objekt gespeichert, das die folgenden Werte hat:

{
   "accountId" : "12321434323",
   "cognitoIdentityPoolId" : "",
   "cognitoIdentityId" : "",
   "sourceIP" : "",
   "caller" : "ThisistheprincipalARN",
   "username" : "username",
   "userArn" : "Sameasabove"
}

Um dieses Objekt in einem UpdateItem DynamoDB-Aufruf zu verwenden, müssen Sie die Benutzeridentitätsinformationen zum Vergleich in der Tabelle speichern. Als Erstes muss Ihre addPost-Mutation den Ersteller speichern. Als Zweites muss Ihre editPost-Mutation vor dem Update die bedingte Prüfung ausführen.

Hier ist ein Beispiel für den Resolver-Code, der addPost die Benutzeridentität als Spalte speichert: 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;

Beachten Sie, dass für das Author-Attribut die Daten aus dem Identity-Objekt der Anwendung übernommen werden.

Abschließend noch ein Beispiel für den Resolver-Code füreditPost, der den Inhalt des Blogbeitrags nur aktualisiert, wenn die Anfrage von dem Benutzer kommt, der den Beitrag erstellt hat:

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;

In diesem Beispiel wird ein verwendetPutItem, das alle Werte überschreibt, und nicht einUpdateItem, aber das gleiche Konzept gilt für den condition Anweisungsblock.

Informationen filtern

Es kann vorkommen, dass Sie die Antwort von Ihrer Datenquelle nicht steuern können, aber keine unnötigen Informationen an Clients in einem erfolgreichen Lese- oder Schreibvorgang der Datenquelle senden möchten. In diesen Fällen können Sie Informationen mithilfe einer Antwortzuweisungsvorlage filtern.

Angenommen, Sie haben keinen geeigneten Index für Ihre DynamoDB-Tabelle in Ihrem Blogbeitrag (z. B. einen Index für). Author Sie könnten den folgenden Resolver verwenden:

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;
}

Der Request-Handler ruft das Element ab, auch wenn der Anrufer nicht der Autor ist, der den Beitrag erstellt hat. Um zu verhindern, dass alle Daten zurückgegeben werden, überprüft der Antworthandler, ob der Anrufer mit dem Autor des Elements übereinstimmt. Wenn der Aufrufer nicht den Prüfkriterien entspricht, wird nur eine Null-Antwort zurückgegeben.

Datenquellenzugriff

AWS AppSync kommuniziert mit Datenquellen mithilfe von Identitäts- und Zugriffsmanagement (IAM) -Rollen und Zugriffsrichtlinien. Wenn Sie eine vorhandene Rolle verwenden, muss eine Vertrauensrichtlinie hinzugefügt werden, damit AWS AppSync diese Rolle übernommen werden kann. Die Vertrauensbeziehung sieht etwa wie folgt aus:

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "appsync.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Es ist wichtig, den Geltungsbereich der Zugriffsrichtlinie für die Rolle so zu verringern, dass nur die Berechtigungen für die minimal erforderliche Ressourcengruppe verfügbar sind. Wenn Sie die AppSync Konsole verwenden, um eine Datenquelle und eine Rolle zu erstellen, erfolgt dies automatisch für Sie. Wenn Sie jedoch eine integrierte Beispielvorlage aus der IAM-Konsole verwenden, um eine Rolle außerhalb der AWS AppSync-Konsole zu erstellen, wird der Berechtigungsumfang nicht automatisch auf eine Ressource beschränkt. Sie sollten dies tun, bevor Sie die Anwendung tatsächlich in Betrieb nehmen.