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. # General/Custom Autorisierungsanforderungen für Connector-Entwickler Die allgemeine Autorisierung ermöglicht es Ihrem Connector, Anmeldeinformationen (wie API-Schlüssel, Token oder username/password Kombinationen) anstelle von OAuth 2.0-Benutzertoken zu verwenden. Im Gegensatz zu OAuth 2.0, das eine Autorisierung auf Benutzerebene durch Kontoverknüpfung ermöglicht, ermöglicht die Allgemeine Autorisierung einen einzigen Satz von Anmeldeinformationen zur Steuerung von Geräten mehrerer Endbenutzer. **Anmerkung** In dieser Dokumentation wird die benutzerdefinierte Autorisierung als allgemeine Autorisierung bezeichnet. Beide Begriffe beschreiben denselben Autorisierungsmechanismus. In den folgenden Abschnitten verwenden wir aus Konsistenzgründen „Allgemeine Autorisierung“. In diesem Abschnitt wird erklärt, wie Sie die Unterstützung für die allgemeine Autorisierung in Ihre AWS Lambda Konnektorfunktion implementieren. Wenn Sie ein Kunde sind, der General Authorization für einen vorhandenen Connector konfiguriert, finden Sie weitere Informationen unter[General/Custom Autorisierungsanforderungen](concepts-general-authorization.md). **Topics** + [Was ist eine allgemeine Autorisierung?](#what-is-general-auth-dev) + [Wie verwendet General Authorization AWS Secrets Manager](#general-auth-secrets-manager-dev) + [Allgemeines Format für Autorisierungsanfragen](#general-auth-request-format) + [Allgemeiner Autorisierungsablauf](#general-auth-workflow-dev) + [Lambda-Berechtigungen für GeneralAuthorization](#general-auth-lambda-permissions-dev) ## Was ist eine allgemeine Autorisierung? Bei der allgemeinen Autorisierung handelt es sich um einen Autorisierungsmechanismus, der nicht auf OAuth basiert und es Ihrem Connector ermöglicht, mithilfe von Kundenanmeldedaten eine Autorisierung bei Plattformen von Drittanbietern vorzunehmen. Bei der Allgemeinen Autorisierung delegiert Managed Integrations die Verwaltung der Anmeldeinformationen an Ihren Connector, und mit einem einzigen Satz von Anmeldeinformationen können Geräte mehrerer Endbenutzer gesteuert werden. Dies ist nützlich für Szenarien, in denen Sie eine Geschäftsbeziehung mit dem Gerätehersteller unterhalten und Geräte in großem Umfang verwalten müssen, ohne dass einzelne Benutzer autorisiert werden müssen. ### Wann sollte die allgemeine Autorisierung verwendet werden Erwägen Sie die Implementierung der Unterstützung für allgemeine Autorisierung in Ihrem Connector, wenn: + Die Drittanbieterplattform unterstützt OAuth 2.0 nicht + Die Drittanbieterplattform bietet benutzerdefiniertes Autorisierungsmaterial wie API-Schlüssel oder Anmeldeinformationen, die sich in folgendem Verzeichnis befinden können AWS Secrets Manager + Sie müssen Geräte in großem Umfang verwalten, ohne dass individuelle Benutzerautorisierungsabläufe erforderlich sind **Anmerkung** Ihr Connector kann beide Autorisierungstypen parallel implementieren und sorgt so für Kompatibilität mit verschiedenen Autorisierungs-Frameworks. ## Wie verwendet General Authorization AWS Secrets Manager AWS Secrets Manager ist ein geheimer Speicherdienst, der vertrauliche Anmeldeinformationen wie API-Schlüssel und Token schützt. Geheimnisse werden mit AWS Key Management Service Schlüsseln verschlüsselt. Weitere Informationen finden Sie im [AWS Secrets Manager -Benutzerhandbuch](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). Für die allgemeine Autorisierung speichern Kunden Autorisierungsdaten im Secrets Manager und gewähren Ihrem C2C-Connector die Erlaubnis, auf diese Geheimnisse zuzugreifen. Wenn Managed Integrations Ihren Connector aufruft, stellt er den Secrets Manager Manager-ARN und die Versions-ID im Anforderungsheader bereit. Ihr Connector ruft den geheimen Wert ab und verwendet ihn zur Autorisierung bei der Drittanbieterplattform. Dieser Ansatz stellt sicher, dass verwaltete Integrationen langfristige Anmeldeinformationen niemals direkt verarbeiten. Ihr Connector behält die volle Kontrolle über die Verwaltung von Anmeldeinformationen und die Token-Generierung, sodass die Lösung auf jeden Autorisierungsmechanismus erweiterbar ist, der von Ihrer Drittanbieterplattform unterstützt wird. **Wichtig** Managed Integrations greift nicht auf die Anmeldeinformationen zu, die im Kundenkonto gespeichert sind, und verwaltet diese auch nicht. AWS Secrets Manager Ihr Connector hat die volle Kontrolle über das Abrufen, Analysieren und Verwenden von Anmeldeinformationen. **Wichtig** Wir empfehlen, dass Sie keine vertraulichen Anmeldeinformationen oder Token in Protokollen protokollieren. Wenn sie jedoch in Protokollen gespeichert werden, empfehlen wir, dass Sie die Datenschutzrichtlinien für CloudWatch Logs verwenden, um die Token in den Protokollen zu maskieren. Weitere Informationen finden Sie unter [Schützen sensibler Protokolldaten durch Maskierung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html). ## Allgemeines Format für Autorisierungsanfragen Wenn Managed Integrations Ihren Connector für eine Kontoverknüpfung mit allgemeiner Autorisierung aufruft, enthält der Anforderungsheader eine AWS Secrets Manager Referenz anstelle eines OAuth-Tokens. Die Anforderungsstruktur ist bei allen Konnektorvorgängen (`AWS.ActivateUser`,`AWS.DiscoverDevices`, `AWS.SendCommand` und) konsistent. `AWS.DeactivateUser` **Example Beispiel: Allgemeine Autorisierungsanfrage** ``` { "header": { "auth": { "secretsManager": { "arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key-AbCdEf", "versionId": "a1b2c3d4-5678-90ab-cdef-1234567890ab" }, "type": "GeneralAuthorization" } }, "payload": { "operationName": "AWS.DiscoverDevices", "operationVersion": "1.0", "connectorId": "Your-Connector-Id", ... } } ``` **Example Beispiel: OAuth 2.0-Anfrage (zum Vergleich)** ``` { "header": { "auth": { "token": "ashriu32yr97feqy7afsaf", "type": "OAuth2.0" } }, "payload": { "operationName": "AWS.DiscoverDevices", "operationVersion": "1.0", "connectorId": "Your-Connector-Id", ... } } ``` **Anmerkung** Ihr Connector muss beide Anforderungsformate verarbeiten. Überprüfen Sie das `auth.type` Feld, um zu bestimmen, welche Autorisierungsmethode für jede Anfrage verwendet werden soll. ## Allgemeiner Autorisierungsablauf Wenn Ihr Connector eine allgemeine Autorisierungsanfrage erhält, gehen Sie wie folgt vor: + **Autorisierungstyp** überprüfen — Überprüfen Sie das `auth.type` Feld im Header der Anfrage, um festzustellen, ob für die Anfrage die allgemeine Autorisierung verwendet wird + **Secrets Manager Manager-Referenz** extrahieren — Extrahieren AWS Secrets Manager Sie den ARN und die Versions-ID aus dem `auth.secretsManager` Objekt + **Geheim abrufen** — Rufen Sie die AWS Secrets Manager `GetSecretValue` API mit dem angegebenen ARN und der Versions-ID auf + **Anmeldeinformationen analysieren — Analysieren** Sie den geheimen Wert, um die Autorisierungsdaten zu extrahieren (das Format hängt von den Anforderungen Ihrer Drittanbieterplattform ab) + **Generieren Sie Token (falls erforderlich)** — Verwenden Sie bei Bedarf die Anmeldeinformationen, um ein Zugriffstoken zu generieren, oder führen Sie zusätzliche Autorisierungsschritte durch, die für die Drittanbieterplattform erforderlich sind + **API-Aufrufe autorisieren** — Verwenden Sie die Anmeldeinformationen oder das generierte Token, um API-Aufrufe an die Drittanbieterplattform zu autorisieren + **Vorgang verarbeiten** — Verarbeiten Sie den Konnektorvorgang (`AWS.DiscoverDevices``AWS.SendCommand`, usw.) mithilfe der autorisierten Verbindung **Anmerkung** Ihr Connector ist für die gesamte Verwaltung der Anmeldeinformationen verantwortlich, einschließlich Token-Generierung, Aktualisierung und Fehlerbehandlung. Managed Integrations stellt nur den Verweis auf das Geheimnis bereit. Die Anmeldeinformationen selbst werden nicht verwaltet. ## Lambda-Berechtigungen für GeneralAuthorization Ihre Connector-Lambda-Ausführungsrolle muss über die Berechtigung verfügen, Geheimnisse von denen des AWS Secrets Manager Kunden abzurufen. Fügen Sie Ihrer Lambda-Ausführungsrollenrichtlinie die folgenden Berechtigungen hinzu: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:*:*:secret:*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager.*.amazonaws.com" } } } ] } ``` **Erklärung der Erlaubnis** + `secretsmanager:GetSecretValue`- Ermöglicht Ihrem Lambda, geheime Werte abzurufen + `kms:Decrypt`- Erforderlich, da Geheimnisse mit Schlüsseln verschlüsselt AWS Key Management Service werden **Anmerkung** Die Beispielrichtlinie ermöglicht den Zugriff auf jedes Geheimnis. In der Produktion sollten Sie das `Resource` Feld nur auf die Geheimnisse beschränken, die Ihr Connector benötigt. Da Kunden jedoch ihre eigenen Geheimnisse erstellen, müssen Sie möglicherweise einen Platzhalter verwenden oder die Benennungskonvention dokumentieren, an die sich die Kunden halten sollten. Der Kunde erteilt Ihrem Lambda über die Ressourcenrichtlinie des Secrets auch die Erlaubnis, auf sein spezifisches Geheimnis zuzugreifen.