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 GraphQL APIs: API-Schlüssel, Lambda, IAM, OpenID Connect und Cognito User Pools. Jede Option bietet eine andere Sicherheitsmethode: 1. **API-Schlüsselautorisierung**: Steuert die Drosselung für nicht authentifizierte Benutzer und bietet so eine APIs einfache Sicherheitsoption. 1. **Lambda-Autorisierung**: Aktiviert eine benutzerdefinierte Autorisierungslogik, die Funktionseingaben und -ausgaben detailliert erklärt. 1. **IAM-Autorisierung**: Nutzt den Signaturprozess AWS der Version 4, der eine differenzierte Zugriffskontrolle durch IAM-Richtlinien ermöglicht. 1. **OpenID Connect-Autorisierung**: Lässt sich in OIDC-konforme Dienste zur Benutzerauthentifizierung integrieren. 1. **Cognito-Benutzerpools**: Implementiert eine gruppenbasierte Zugriffskontrolle mithilfe der Benutzerverwaltungsfunktionen von Cognito. ## Autorisierungstypen 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 Autorisierungstypwerte angeben: + ** `API_KEY` ** Für die Verwendung von API-Schlüsseln. + ** `AWS_LAMBDA` ** Für die Verwendung einer AWS Lambda Funktion. + ** `AWS_IAM` ** Für die Verwendung von AWS Identity and Access Management ([IAM](https://aws.amazon.com/iam/) -) Berechtigungen. + ** `OPENID_CONNECT` ** Für die Verwendung Ihres OpenID Connect-Anbieters. + ** `AMAZON_COGNITO_USER_POOLS` ** Für die Verwendung eines Amazon Cognito Cognito-Benutzerpools. 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 hinzufügen AWS CloudFormation. 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`, und`AMAZON_COGNITO_USER_POOLS`). Wenn Sie `API_KEY``AWS_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. Wenn Sie Änderungen an Ihrer API-Konfiguration speichern, AWS AppSync beginnt die Übertragung der Änderungen. Solange Ihre Konfigurationsänderung nicht übernommen wurde, werden AWS AppSync weiterhin Ihre Inhalte aus der vorherigen Konfiguration bereitgestellt. Sobald Ihre Konfigurationsänderung übernommen wurde, wird AWS AppSync sofort mit der Bereitstellung Ihrer Inhalte auf der Grundlage der neuen Konfiguration begonnen. Während AWS AppSync Ihre Änderungen für eine API übertragen werden, können wir nicht anhand der vorherigen Konfiguration oder der neuen Konfiguration feststellen, ob die API Ihre Inhalte bereitstellt. ## API\_KEY Autorisierung Für nicht authentifizierte ist eine strengere Drosselung APIs erforderlich als für 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](https://docs.aws.amazon.com/appsync/latest/APIReference/) aus rotieren. ------ #### [ Console ] 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/). 1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus. 1. **Wählen Sie in der **Seitenleiste** Einstellungen.** 1. Wählen Sie unter **Standardautorisierungsmodus** die Option **API-Schlüssel** aus. 1. 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 wählen Sie dann **Löschen**. 1. 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](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html). 1. Erstellen Sie ein GraphQL-API-Objekt, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html)Befehl ausführen. Sie müssen zwei Parameter für diesen speziellen Befehl eingeben: 1. Die `api-id` Ihrer GraphQL-API. 1. Das Neue `name` Ihrer API. Sie können dasselbe verwenden`name`. 1. Das`authentication-type`, was sein wird`API_KEY`. **Anmerkung** Es gibt andere Parameter wie diesen`Region`, die konfiguriert werden müssen, aber normalerweise werden sie standardmäßig auf Ihre CLI-Konfigurationswerte gesetzt. 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 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 AWS Lambda Funktion implementieren. Sie können eine Lambda-Funktion entweder für Ihren primären oder sekundären Autorisierer verwenden, aber es kann nur eine Lambda-Autorisierungsfunktion pro API geben. Bei der Verwendung von Lambda-Funktionen für die Autorisierung gilt Folgendes: + Wenn für die API die Modi `AWS_LAMBDA` und `AWS_IAM` Autorisierung aktiviert sind, kann die SigV4-Signatur nicht als `AWS_LAMBDA` Autorisierungstoken verwendet werden. + Wenn für die API die `OPENID_CONNECT` Autorisierungsmodi `AWS_LAMBDA` und oder der `AMAZON_COGNITO_USER_POOLS` Autorisierungsmodus aktiviert sind, kann das OIDC-Token nicht als Autorisierungstoken verwendet werden. `AWS_LAMBDA` Beachten Sie, dass es sich bei dem OIDC-Token um ein Bearer-Schema handeln kann. + Eine Lambda-Funktion darf nicht mehr als 5 MB an Kontextdaten für Resolver zurückgeben. 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. Wenn eine Lambda-Autorisierungsantwort weniger als 1.048.576 Byte umfasst, wird die Antwort für nachfolgende Anfragen AWS AppSync zwischengespeichert. Wenn die Antwort des Lambda-Autorisierers gleich oder größer als 1.048.576 Byte ist, wird die Antwort AWS AppSync nicht zwischengespeichert und der Lambda-Authorizer wird für jede eingehende Anfrage aufgerufen. Um die Leistung zu optimieren und die Kosten für Lambda-Aufrufe zu minimieren, empfehlen wir Ihnen, Ihre Lambda-Autorisierungsantworten auf 1.048.576 Byte zu beschränken. Standardmäßig ist das Caching nicht aktiviert, aber es kann auf API-Ebene oder durch Setzen 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, 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](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) 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ückgeben`isAuthorized`, der angibt, ob die Anfrage autorisiert ist. AWS AppSync erkennt die folgenden Schlüssel, die von Lambda-Autorisierungsfunktionen zurückgegeben wurden: **Anmerkung** Der Wert für den `operationName` in der Operation `requestContext` for a WebSocket connect wird mit "`DeepDish:Connect`" AWS AppSync gesetzt. ### Funktionsliste `isAuthorized`(boolescher Wert, erforderlich) Ein boolescher Wert, der angibt, ob der Wert in berechtigt `authorizationToken` ist, Aufrufe an die GraphQL-API zu tätigen. Wenn dieser Wert wahr ist, wird die Ausführung der GraphQL-API fortgesetzt. Wenn dieser Wert falsch ist, `UnauthorizedException` wird an ausgelöst `deniedFields`(Liste der Zeichenketten, optional) Eine Liste, in die zwangsweise geändert wird`null`, auch wenn ein Wert von einem Resolver zurückgegeben wurde. Jeder Artikel ist entweder ein vollständig qualifizierter Feld-ARN in der Form von `arn:aws:appsync:{{us-east-1}}:{{111122223333}}:apis/{{GraphQLApiId}}/types/{{TypeName}}/fields/{{FieldName}}` oder eine Kurzform von`{{TypeName}}.{{FieldName}}`. Das vollständige ARN-Formular sollte verwendet werden, wenn sich zwei einen Lambda-Funktionsautorisierer APIs teilen und es zu Unklarheiten zwischen gemeinsamen Typen und Feldern zwischen den beiden kommen kann. APIs `resolverContext`(JSON-Objekt, optional) Ein JSON-Objekt, das wie `$ctx.identity.resolverContext` in Resolver-Vorlagen sichtbar ist. Zum Beispiel, wenn die folgende Struktur von einem Resolver zurückgegeben wird: ``` { "isAuthorized":true "resolverContext": { "banana":"very yellow", "apple":"very green" } } ``` Der Wert von `ctx.identity.resolverContext.apple` in Resolver-Vorlagen wird "“ `very green` sein. Das `resolverContext` Objekt unterstützt nur Schlüssel-Wert-Paare. Verschachtelte Schlüssel werden nicht unterstützt. Die Gesamtgröße dieses JSON-Objekts darf 5 MB nicht überschreiten. `ttlOverride`(Ganzzahl, optional) Die Anzahl der Sekunden, für die die Antwort zwischengespeichert werden soll. Wenn kein Wert zurückgegeben wird, wird der Wert aus der API verwendet. Wenn dieser Wert 0 ist, wird die Antwort nicht zwischengespeichert. Lambda-Autorisierer haben ein Standard-Timeout von 10 Sekunden, bei Spitzenverkehr kann es jedoch zu einem früheren Timeout kommen. Wir empfehlen, Funktionen so zu entwerfen, dass sie in möglichst kurzer Zeit (unter 1 Sekunde) ausgeführt werden, um die Leistung Ihrer API zu skalieren. Mehrere AWS AppSync APIs können sich eine einzige Authentifizierungs-Lambda-Funktion teilen. Die kontoübergreifende Verwendung von Autorisierern ist nicht zulässig. Wenn Sie eine Autorisierungsfunktion von mehreren Personen gemeinsam nutzen APIs, beachten Sie, dass Kurzform-Feldnamen (`{{typename}}.{{fieldname}}`) versehentlich Felder verbergen können. Um ein Feld in eindeutig zu kennzeichnen`deniedFields`, können Sie einen eindeutigen Feld-ARN in der Form von angeben. `arn:aws:appsync:{{region}}:{{accountId}}:apis/{{GraphQLApiId}}/types/{{typeName}}/fields/{{fieldName}}` 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 API, die Sie aktualisieren möchten. 1. Navigieren Sie zur Einstellungsseite für Ihre API. Ändern Sie die Autorisierung auf API-Ebene auf. **AWS Lambda** 1. Wählen Sie den AWS-Region und den Lambda-ARN aus, für den API-Aufrufe autorisiert werden sollen. **Anmerkung** Die entsprechende Prinzipalrichtlinie wird automatisch hinzugefügt, sodass AWS AppSync Sie Ihre Lambda-Funktion aufrufen können. 1. Legen Sie optional die Antwort-TTL 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 “{{}}” --output text ``` 1. 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 der Autorisierungsbeschränkungen für SigV4- und OIDC-Tokens 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 Autorisierungsmodi `AWS_IAM` und die `AWS_LAMBDA` Autorisierungsmodi für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor: + Um ein neues Lambda-Autorisierungstoken zu erstellen, fügen Sie der SigV4-Signatur zufällige and/or Suffix-Präfixe hinzu. + Um die ursprüngliche Sigv4-Signatur abzurufen, aktualisieren Sie Ihre Lambda-Funktion, indem Sie die zufälligen and/or Präfix-Suffixe aus dem Lambda-Autorisierungstoken entfernen. Verwenden Sie dann die ursprüngliche SigV4-Signatur zur Authentifizierung. Wenn Sie das OIDC-Token als Lambda-Autorisierungstoken verwenden möchten, wenn der Autorisierungsmodus oder die `OPENID_CONNECT` Autorisierungsmodi `AMAZON_COGNITO_USER_POOLS` und die `AWS_LAMBDA` Autorisierungsmodi für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor: + Um ein neues Lambda-Autorisierungstoken zu erstellen, fügen Sie dem OIDC-Token zufällige and/or Suffix-Präfixe hinzu. Das Lambda-Autorisierungstoken sollte kein Bearer-Schema-Präfix enthalten. + Um das ursprüngliche OIDC-Token abzurufen, aktualisieren Sie Ihre Lambda-Funktion, indem Sie die zufälligen and/or Präfix-Suffixe aus dem Lambda-Autorisierungstoken entfernen. Verwenden Sie dann das ursprüngliche OIDC-Token zur Authentifizierung. ## AWS\_IAM Autorisierung Dieser Autorisierungstyp erzwingt den [AWS Signaturprozess der Signaturversion 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) auf der GraphQL-API. Sie können vordefinierte Zugriffsrichtlinien für Identity and Access Management ([IAM](https://aws.amazon.com/iam/)) mit diesem Autorisierungstyp verknüpfen. 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: ------ #### [ JSON ] **** ``` { "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 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/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/" ] } ] } ``` ------ 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: ------ #### [ 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](https://openid.net/specs/openid-connect-core-1_0.html) (OIDC) -Token, die von einem OIDC-kompatiblen Dienst bereitgestellt werden. 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 [hängt `/.well-known/openid-configuration` an die Aussteller-URL an und lokalisiert 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 wird erwartet, dass unter dieser URL ein [RFC5785](https://tools.ietf.org/html/rfc5785)konformes JSON-Dokument abgerufen wird. 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. | Signaturalgorithmen | | --- | | RS256 | | RS384 | | RS512 | | PS256 | | PS384 | | PS512 | | HS256 | | HS384 | | HS512 | | ES256 | | ES384 | | ES512 | 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 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 MG verfügt, würden Sie, um nur die ersten drei Clients zu validieren, 1F4G9H\|1J6L4B\|6 GS5 MG in das Feld Client-ID eingeben. IDs GS5 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 mit der in der API-Konfiguration angegebenen Aussteller-URL verglichen wird. Wenn eine API jedoch nur mit OPENID\_CONNECT Autorisierung konfiguriert ist, wird dieser Schritt zur Überprüfung der Aussteller-URL AWS AppSync übersprungen. ## 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-Operationen 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 Ihre 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 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 fungiert als Standard im 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. 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: + `@aws_api_key` – Zur Angabe, dass das Feld `API_KEY`-autorisiert ist. + `@aws_iam` – Zur Angabe, dass das Feld `AWS_IAM`-autorisiert ist. + `@aws_oidc` – Zur Angabe, dass das Feld `OPENID_CONNECT`-autorisiert ist. + `@aws_cognito_user_pools` – Zur Angabe, dass das Feld `AMAZON_COGNITO_USER_POOLS`-autorisiert ist. + `@aws_lambda` – Zur Angabe, dass das Feld `AWS_LAMBDA`-autorisiert ist. 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 auf 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 (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](#aws-appsync-filtering-information) 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](resolver-mapping-template-reference.md#aws-appsync-resolver-mapping-template-reference) [für DynamoDB](resolver-mapping-template-reference-dynamodb.md#aws-appsync-resolver-mapping-template-reference-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, ihn 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. ![Vierstufiger Workflow, der das Abrufen von Token, das Senden von Anfragen, die bedingte Prüfung und die Ausführung von Vorgängen zeigt.](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/FGAC.png) 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ür`addPost`, 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ür`editPost`, 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 verwendet`PutItem`, das alle Werte überschreibt, und nicht ein`UpdateItem`, 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](https://aws.amazon.com/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: ------ #### [ 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.