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 von Autorisierung und Authentifizierung zur Sicherung Ihres GraphQL APIs

AWS AppSync bietet die folgenden Autorisierungstypen zur Sicherung von GraphQLAPIs: API Schlüssel, LambdaIAM, OpenID Connect und Cognito User Pools. Jede Option bietet eine andere Sicherheitsmethode:

Autorisierungstypen

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

Diese grundlegenden Autorisierungstypen funktionieren für die meisten Entwickler. Für fortgeschrittenere Anwendungsfälle können Sie zusätzliche Autorisierungsmodi über die KonsoleCLI, 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 API_KEYAWS_LAMBDA, oder AWS_IAM als Haupt- oder Standardautorisierungstyp angeben, können Sie sie nicht erneut als einen der zusätzlichen Autorisierungsmodi angeben. 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 Cognito-Benutzerpools und OpenID Connect-Anbieter verwenden. Sie können jedoch keine doppelten Amazon Cognito Cognito-Benutzerpools oder OpenID Connect-Anbieter zwischen dem Standardautorisierungsmodus und einem der zusätzlichen Autorisierungsmodi verwenden. Sie können verschiedene Clients für Ihren Amazon Cognito Cognito-Benutzerpool oder OpenID Connect-Anbieter angeben, indem Sie den entsprechenden regulären Konfigurationsausdruck verwenden.

API_KEYAutorisierung

Für nicht authentifizierte ist eine strengere Drosselung APIs erforderlich als für authentifizierte. APIs Eine Möglichkeit, die Drosselung für nicht authentifizierte GraphQL-Endpunkte zu kontrollieren, ist die Verwendung von Schlüsseln. API Ein API Schlüssel ist ein fest codierter Wert in Ihrer Anwendung, der vom AWS AppSync Dienst generiert wird, wenn Sie einen nicht authentifizierten GraphQL-Endpunkt erstellen. Sie können API Schlüssel von der Konsole, von der oder von der CLI Referenz aus rotieren.AWS AppSync API

Console

1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die AppSyncKonsole.

   1. Wählen Sie im APIsDashboard Ihr GraphQL API aus.

   2. Wählen Sie in der Seitenleiste Einstellungen.

2. Wählen Sie unter Standardautorisierungsmodus die Option APISchlüssel aus.

3. Wählen Sie in der APISchlüsseltabelle die Option APISchlü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 wählen Sie dann 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 den AWS CLI. Weitere Informationen finden Sie unter Grundlagen der Konfiguration.

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

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

   1. Das api-id von deinem GraphQLAPI.

   2. Das neue name von dirAPI. Du kannst dasselbe verwendenname.

   3. Dasauthentication-type, was sein wirdAPI_KEY.

   Anmerkung

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

   Ein Beispielbefehl könnte wie folgt aussehen:

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

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

APISchlüssel können für bis zu 365 Tage konfiguriert werden, und Sie können ein vorhandenes Ablaufdatum ab diesem Tag um weitere 365 Tage verlängern. APISchlüssel werden für Entwicklungszwecke oder für Anwendungsfälle empfohlen, in denen es sicher ist, der Öffentlichkeit zugänglich zu machenAPI.

Auf dem Client wird der API Schlüssel durch den Header spezifiziertx-api-key.

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_LAMBDAAutorisierung

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

Wenn Ihr Autorisierungstoken beispielsweise lautet'ABC123', können Sie eine GraphQL-Abfrage über curl wie folgt 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. Standardmäßig ist das Caching nicht aktiviert, aber es kann auf der API Ebene aktiviert werden oder indem der ttlOverride Wert im Rückgabewert einer Funktion festgelegt wird.

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, erfordern, appsync.amazonaws.com dass eine Hauptrichtlinie auf sie angewendet wird, AWS AppSync damit sie aufgerufen werden 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 Ressourcenbasierte Richtlinien im Entwicklerhandbuch. AWS Lambda

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 Anfrage autorisiert ist. AWS AppSync erkennt die folgenden Schlüssel, die von Lambda-Autorisierungsfunktionen zurückgegeben wurden:

Um eine Lambda-Funktion als Standard-Autorisierungsmodus hinzuzufügen in AWS AppSync:

Console

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

2. Navigieren Sie zur Einstellungsseite für IhreAPI.

   Ändern Sie die Autorisierung API auf -Stufe auf. AWS Lambda

3. Wählen Sie das AWS-Region und Lambda ausARN, gegen das API Anrufe autorisiert werden sollen.

   Anmerkung

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

4. Legen Sie optional den regulären Ausdruck für die Antwort TTL und die Tokenvalidierung 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 auf ein einzelnes GraphQL beschränkt istAPI, 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 die angegebene Lambda-Funktion ARN 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 haben 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 von SigV4- und Token-Autorisierungsbeschränkungen OIDC

Die folgenden Methoden können verwendet werden, um das Problem zu umgehen, dass Sie Ihre SigV4-Signatur oder OIDC Ihr SigV4-Signaturen 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 -modi für AWS AppSync'aktiviert sindAPI, gehen Sie wie folgt vor:

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

AWS_IAMAutorisierung

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

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

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

Sie finden es auf YourGraphQLApiId der Hauptseite mit dem API Angebot in der AppSync Konsole direkt unter Ihrem Namen. API Alternativ kannst du es mit dem folgenden Befehl abrufenCLI: 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.

{
   "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 Cognito-Identitätspool anhängen könnten) würde wie folgt aussehen:

{
    "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 OIDC -kompatiblen Dienst bereitgestellt werden. Ihre Anwendung kann die von Ihrem OIDC Anbieter definierten Benutzer und Rechte zur Zugriffskontrolle nutzen.

Ein Aussteller URL ist der einzige erforderliche Konfigurationswert, den Sie angeben AWS AppSync (z. B.https://auth.example.com). Dieser URL muss über adressierbar sein. HTTPS AWS AppSync hängt an den Aussteller /.well-known/openid-configuration an URL und lokalisiert die OpenID-Konfiguration https://auth.example.com/.well-known/openid-configuration gemäß der OpenID Connect Discovery-Spezifikation. Es wird erwartet, dass dabei ein konformes Dokument abgerufen wird RFC5785. JSON URL Dieses JSON Dokument muss einen jwks_uri Schlüssel enthalten, der auf das JSON Web Key Set (JWKS) -Dokument mit den Signaturschlüsseln verweist. AWS AppSync erfordertJWKS, dass die JSON Felder kty und enthaltenkid.

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 in Ihrer OpenID Connect-Konfiguration TTL Werte für die Ausstellungszeit (iatTTLauthTTL) und die Authentifizierungszeit () zur zusätzlichen Überprüfung angeben. 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 das in Ihrer OpenID Connect-Konfiguration vorhanden clientId ist, AWS AppSync validiert es den Anspruch, indem es verlangt, dass der clientId entweder mit dem aud oder azp -Anspruch im Token übereinstimmt.

Um mehrere Clients zu validieren, IDs verwenden Sie den Pipeline-Operator („|“), der im regulären Ausdruck ein „oder“ ist. Wenn Ihre OIDC Anwendung beispielsweise über vier Clients mit einem Client IDs wie 0A1S2D, 1F4G9H, 1J6L4B, 6 verfügt, würden Sie, um nur die ersten drei Clients zu validieren, 1F4G9H|1J6L4B|6 GS5MG in das Feld Client-ID eingeben. IDs GS5MG

AMAZON_COGNITO_USER_POOLS Autorisierung

Dieser Autorisierungstyp erzwingt OIDC Token, die von Amazon Cognito Cognito-Benutzerpools bereitgestellt werden. Ihre Anwendung kann die Benutzer und Gruppen sowohl in Ihren Benutzerpools als auch in Benutzerpools von einem anderen AWS Konto nutzen und diese mit GraphQL-Feldern verknüpfen, um den Zugriff zu kontrollieren.

Wenn Sie Amazon Cognito User Pools 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 AWS AppSync GraphQL-Vorgängen 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 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 Direktive weglassen können, wenn Sie standardmäßig eine bestimmte grant-or-deny Zugriffsstrategie verwenden möchten. Sie können die grant-or-deny Strategie in der Benutzerpool-Konfiguration angeben, wenn Sie Ihr GraphQL API über die Konsole oder über den folgenden CLI Befehl erstellen:

$ 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 AWS AppSync API GraphQL-Ebene konfigurieren (d. h. das authenticationType Feld, das Sie direkt für das GraphqlApi Objekt konfigurieren können) und sie fungiert als Standard im Schema. Das bedeutet, dass jeder Typ, der keine spezifische Direktive hat, die API Level-Autorisierungseinstellung bestehen 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. Beispielsweise würden Sie für die API_KEY-Autorisierung für Schemaobjekttypdefinitionen/-felder @aws_api_key verwenden. 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 für 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 für AWS AppSync GraphQL API_KEY API konfiguriert haben und Sie können ein Feld mithilfe der @aws_api_key Direktive markieren (z. B. 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
}
...

Differenzierte 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, falls Sie mit Mapping-Vorlagen in nicht vertraut sind AWS AppSync, die Resolver-Mapping-Vorlagenreferenz und die Resolver-Mapping-Vorlagenreferenz für DynamoDB lesen.

Gehen Sie im folgenden Beispiel mit DynamoDB davon aus, dass Sie das vorherige Blogbeitragsschema verwenden und dass nur Benutzer, die einen Beitrag erstellt haben, diesen bearbeiten dürfen. 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 eine Bearbeitungsoperation handelt, entspricht sie einer 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 füraddPost, der 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.

Nehmen wir beispielsweise an, Sie haben keinen geeigneten Index in der DynamoDB-Tabelle für Ihren 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 Aufrufer 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 Identity and Access Management (IAM) -Rollen und Zugriffsrichtlinien. Wenn Sie eine bestehende Rolle verwenden, muss eine Vertrauensrichtlinie hinzugefügt werden, um die Rolle übernehmen AWS AppSync zu können. Die Vertrauensbeziehung sieht etwa wie folgt aus:

{
    "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, werden die Berechtigungen nicht automatisch auf eine Ressource beschränkt. Sie sollten diese Aktion ausführen, bevor Sie Ihre Anwendung in die Produktionsumgebung überführen.