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.
# Arbeiten mit Amazon Cognito Identitätsquellen
Verified Permissions arbeitet eng mit Amazon Cognito Cognito-Benutzerpools zusammen. Amazon Cognito JWTs haben eine vorhersehbare Struktur. Verified Permissions erkennt diese Struktur und zieht den größtmöglichen Nutzen aus den darin enthaltenen Informationen. Sie können beispielsweise ein Autorisierungsmodell für die rollenbasierte Zugriffskontrolle (RBAC) implementieren, das entweder ID-Token oder Zugriffstoken verwendet.
Die Identitätsquelle eines neuen Amazon Cognito Cognito-Benutzerpools benötigt die folgenden Informationen:
+ Das AWS-Region.
+ Die Benutzerpool-ID.
+ Der Haupt-Entitätstyp, den Sie Ihrer Identitätsquelle zuordnen möchten, zum Beispiel`MyCorp::User`.
+ Der Entitätstyp der Prinzipalgruppe, den Sie Ihrer Identitätsquelle zuordnen möchten`MyCorp::UserGroup`.
+ Der Client IDs aus Ihrem Benutzerpool, den Sie autorisieren möchten, Anfragen an Ihren Richtlinienspeicher zu stellen.
Da Verified Permissions nur mit Amazon Cognito Cognito-Benutzerpools in demselben funktioniert AWS-Konto, können Sie keine Identitätsquelle in einem anderen Konto angeben. Verified Permissions legt beispielsweise das *Entitätspräfix* — die ID der Identitätsquelle, auf die Sie in Richtlinien verweisen müssen, die sich auf Benutzerpool-Prinzipale beziehen — auf die ID Ihres Benutzerpools fest. `us-west-2_EXAMPLE` In diesem Fall würden Sie auf einen Benutzer in diesem Benutzerpool mit der ID als verweisen `a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`
*Ansprüche* auf Benutzerpool-Tokens können Attribute, Bereiche, Gruppen IDs, Client- und benutzerdefinierte Daten enthalten. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)verfügen über die Fähigkeit, eine Vielzahl von Informationen, die zu Autorisierungsentscheidungen beitragen können, in Verifizierte Berechtigungen aufzunehmen. Dazu zählen:
1. Benutzername und Gruppenansprüche mit einem `cognito:` Präfix
1. [Benutzerdefinierte Benutzerattribute](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) mit einem `custom: prefix`
1. Zur Laufzeit hinzugefügte benutzerdefinierte Ansprüche
1. OIDC-Standardansprüche wie und `sub` `email`
Wir behandeln diese Ansprüche ausführlich und erfahren, wie sie verwaltet werden, in den Richtlinien für verifizierte Berechtigungen, unter. [Zuordnen von Amazon Cognito Tokens zum Schema](cognito-map-token-to-schema.md)
**Wichtig**
Sie können Amazon Cognito Token zwar vor deren Ablauf widerrufen, JWTs gelten jedoch als zustandslose Ressourcen, die eigenständig sind und über eine Signatur und Gültigkeit verfügen. Von Diensten, die [dem JSON Web Token RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) entsprechen, wird erwartet, dass sie Token remote validieren und müssen sie nicht beim Emittenten validieren. Das bedeutet, dass es verifizierten Berechtigungen möglich ist, Zugriff auf der Grundlage eines Tokens zu gewähren, das für einen Benutzer gesperrt oder ausgestellt und später gelöscht wurde. Um dieses Risiko zu minimieren, empfehlen wir Ihnen, Ihre Token mit der kürzest möglichen Gültigkeitsdauer zu erstellen und Aktualisierungstoken zu widerrufen, wenn Sie die Autorisierung zur Fortsetzung der Sitzung eines Benutzers entfernen möchten. Weitere Informationen finden Sie unter [Benutzersitzungen mit Token-Widerruf beenden](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)
Das folgende Beispiel zeigt, wie Sie eine Richtlinie erstellen könnten, die auf einige Ansprüche der Amazon Cognito Cognito-Benutzerpools verweist, die mit einem Prinzipal verknüpft sind.
```
permit(
principal,
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
)
when {
principal["cognito:username"]) == "alice" &&
principal["custom:department"]) == "Finance"
};
```
Das folgende Beispiel zeigt, wie Sie eine Richtlinie erstellen können, die auf einen Prinzipal verweist, der ein Benutzer in einem Cognito-Benutzerpool ist. Beachten Sie, dass die Prinzipal-ID die Form von `"|"` hat.
```
permit(
principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
);
```
Die Richtlinien von Cedar für Identitätsquellen in Benutzerpools in Verified Permissions verwenden eine spezielle Syntax für Anspruchsnamen, die andere Zeichen als alphanumerische Zeichen und Unterstriche () `_` enthalten. Dazu gehören auch Ansprüche auf Benutzerpool-Präfixe, die ein `:` Zeichen wie `cognito:username` und enthalten. `custom:department` Um eine Richtlinienbedingung zu schreiben, die auf den `custom:department` Anspruch `cognito:username` oder verweist, schreiben Sie sie jeweils als `principal["cognito:username"]` und`principal["custom:department"]`.
**Anmerkung**
Wenn ein Token einen Anspruch mit dem `custom:` Präfix `cognito:` oder und einen Anspruchsnamen mit dem wörtlichen Wert `cognito` oder enthält`custom`, schlägt eine Autorisierungsanfrage mit a [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)`ValidationException`fehl.
Weitere Informationen zur Zuordnung von Ansprüchen finden Sie unter[Zuordnen von Amazon Cognito Tokens zum Schema](cognito-map-token-to-schema.md). Weitere Informationen zur Autorisierung von Amazon Cognito Benutzern finden Sie unter [Autorisierung mit von Amazon verifizierten Berechtigungen](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) im *Amazon Cognito Developer Guide*.
**Topics**
+ [Amazon Cognito Identitätsquellen für Amazon Verified Permissions erstellen](cognito-create.md)
+ [Amazon Cognito Identitätsquellen für Amazon Verified Permissions bearbeiten](cognito-edit.md)
+ [Zuordnen von Amazon Cognito Tokens zum Schema](cognito-map-token-to-schema.md)
+ [Kunden- und Zielgruppenvalidierung für Amazon Cognito](cognito-validation.md)
# Amazon Cognito Identitätsquellen für Amazon Verified Permissions erstellen
Mit dem folgenden Verfahren wird einem vorhandenen Richtlinienspeicher eine Identitätsquelle hinzugefügt.
Sie können auch eine Identitätsquelle erstellen, wenn Sie in der Konsole „Verifizierte Berechtigungen“ [einen neuen Richtlinienspeicher erstellen](policy-stores-create.md). In diesem Prozess können Sie die Ansprüche in Ihren Identitätsquellen-Token automatisch in Entitätsattribute importieren. Wählen Sie die Option **„Geführte Einrichtung****“ oder „Einrichtung mit API Gateway und einem Identitätsanbieter**“. Mit diesen Optionen werden auch erste Richtlinien erstellt.
**Anmerkung**
**Identitätsquellen** sind im Navigationsbereich auf der linken Seite erst verfügbar, wenn Sie einen Richtlinienspeicher erstellt haben. Identitätsquellen, die Sie erstellen, sind dem aktuellen Richtlinienspeicher zugeordnet.
Sie können den Hauptentitätstyp weglassen, wenn Sie eine Identitätsquelle mit [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)in der AWS CLI oder [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)in der Verified Permissions API erstellen. Ein leerer Entitätstyp erstellt jedoch eine Identitätsquelle mit dem Entitätstyp`AWS::Cognito`. Dieser Entitätsname ist nicht mit dem Richtlinienspeicherschema kompatibel. Um Amazon Cognito Identitäten in Ihr Policy-Speicher-Schema zu integrieren, müssen Sie den Prinzipal-Entitätstyp auf eine unterstützte Policy-Store-Entität festlegen.
------
#### [ AWS-Managementkonsole ]
**So erstellen Sie eine Identitätsquelle für Amazon Cognito Cognito-Benutzerpools**
1. Öffnen Sie die [Konsole Verified Permissions](https://console.aws.amazon.com/verifiedpermissions/). Wählen Sie Ihren Richtlinienspeicher aus.
1. Wählen Sie im Navigationsbereich auf der linken Seite **Identitätsquellen aus**.
1. Wählen Sie **Identitätsquelle erstellen aus**.
1. Wählen Sie in den **Cognito-Benutzerpooldetails** die **Benutzerpool-ID** für Ihre Identitätsquelle aus AWS-Region und geben Sie sie ein.
1. Wählen Sie in der **Prinzipalkonfiguration** für **Principal Type** den Entitätstyp für Principals aus dieser Quelle aus. Identitäten aus den verbundenen Amazon Cognito Cognito-Benutzerpools werden dem ausgewählten Prinzipaltyp zugeordnet.
1. Wählen Sie in der **Gruppenkonfiguration** die Option **Cognito-Gruppe verwenden** aus, wenn Sie den `cognito:groups` Benutzerpoolanspruch zuordnen möchten. Wählen Sie einen Entitätstyp, der dem Prinzipaltyp übergeordnet ist.
1. Wählen Sie unter **Validierung der Client-Anwendung** aus, ob die Client-Anwendung validiert werden soll IDs.
+ Um die Client-Anwendung zu validieren IDs, wählen Sie **Nur Tokens mit passender Client-Anwendung akzeptieren IDs**. Wählen Sie **Neue Client-Anwendungs-ID hinzufügen** für jede zu validierende Client-Anwendungs-ID aus. Um eine hinzugefügte Client-Anwendungs-ID zu **entfernen**, klicken Sie neben der Client-Anwendungs-ID auf Entfernen.
+ Wählen **Sie Client-Anwendung nicht validieren IDs**, wenn Sie die Client-Anwendung nicht validieren möchten IDs.
1. Wählen Sie **Identitätsquelle erstellen**.
1. (Optional) Wenn Ihr Richtlinienspeicher über ein Schema verfügt, müssen Sie, bevor Sie in Ihren Cedar-Richtlinien auf Attribute verweisen können, die Sie aus Identitäts- oder Zugriffstoken extrahieren, Ihr Schema aktualisieren, damit Cedar weiß, welche Art von Prinzipal Ihre Identitätsquelle erstellt. Diese Ergänzung zum Schema muss die Attribute enthalten, auf die Sie in Ihren Cedar-Richtlinien verweisen möchten. Weitere Informationen zur Zuordnung von Amazon Cognito Tokenattributen zu Cedar-Prinzipalattributen finden Sie unter[Zuordnen von Amazon Cognito Tokens zum Schema](cognito-map-token-to-schema.md).
**Anmerkung**
Wenn Sie einen [API-verknüpften Richtlinienspeicher](policy-stores-api-userpool.md) erstellen oder „**Setup with“ API Gateway und einen Identitätsanbieter** beim Erstellen von Richtlinienspeichern verwenden, fragt Verified Permissions Ihren Benutzerpool nach Benutzerattributen ab und erstellt ein Schema, in dem Ihr Prinzipaltyp mit Benutzerpool-Attributen gefüllt wird.
1. Erstellen Sie Richtlinien, die Informationen aus den Tokens verwenden, um Autorisierungsentscheidungen zu treffen. Weitere Informationen finden Sie unter [Statische Richtlinien für Amazon Verified Permissions erstellen](policies-create.md).
Nachdem Sie nun eine Identitätsquelle erstellt, das Schema aktualisiert und Richtlinien erstellt haben, lassen Sie zunächst `IsAuthorizedWithToken` Verifizierte Berechtigungen Autorisierungsentscheidungen treffen. Weitere Informationen finden Sie [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)im *Referenzhandbuch zur Amazon Verified Permissions API*.
------
#### [ AWS CLI ]
**So erstellen Sie eine Identitätsquelle für Amazon Cognito Cognito-Benutzerpools**
Sie können mithilfe des [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)Vorgangs eine Identitätsquelle erstellen. Im folgenden Beispiel wird eine Identitätsquelle erstellt, die auf authentifizierte Identitäten aus einem Amazon Cognito Benutzerpool zugreifen kann.
1. Erstellen Sie eine `config.txt` Datei, die die folgenden Details des Amazon Cognito Benutzerpools zur Verwendung durch den `--configuration` Parameter im Befehl enthält. `create-identity-source`
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Führen Sie den folgenden Befehl aus, um eine Amazon Cognito Identitätsquelle zu erstellen.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (Optional) Wenn Ihr Richtlinienspeicher über ein Schema verfügt, müssen Sie, bevor Sie in Ihren Cedar-Richtlinien auf Attribute verweisen können, die Sie aus Identitäts- oder Zugriffstoken extrahieren, Ihr Schema aktualisieren, damit Cedar weiß, welche Art von Prinzipal Ihre Identitätsquelle erstellt. Diese Ergänzung zum Schema muss die Attribute enthalten, auf die Sie in Ihren Cedar-Richtlinien verweisen möchten. Weitere Informationen zur Zuordnung von Amazon Cognito Tokenattributen zu Cedar-Prinzipalattributen finden Sie unter[Zuordnen von Amazon Cognito Tokens zum Schema](cognito-map-token-to-schema.md).
**Anmerkung**
Wenn Sie einen [API-verknüpften Richtlinienspeicher](policy-stores-api-userpool.md) erstellen oder „**Setup with“ API Gateway und einen Identitätsanbieter** beim Erstellen von Richtlinienspeichern verwenden, fragt Verified Permissions Ihren Benutzerpool nach Benutzerattributen ab und erstellt ein Schema, in dem Ihr Prinzipaltyp mit Benutzerpool-Attributen gefüllt wird.
1. Erstellen Sie Richtlinien, die Informationen aus den Tokens verwenden, um Autorisierungsentscheidungen zu treffen. Weitere Informationen finden Sie unter [Statische Richtlinien für Amazon Verified Permissions erstellen](policies-create.md).
Nachdem Sie nun eine Identitätsquelle erstellt, das Schema aktualisiert und Richtlinien erstellt haben, lassen Sie zunächst `IsAuthorizedWithToken` Verifizierte Berechtigungen Autorisierungsentscheidungen treffen. Weitere Informationen finden Sie [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)im *Referenzhandbuch zur Amazon Verified Permissions API*.
------
Weitere Informationen zur Verwendung von Zugriffs- und Identitätstoken von Amazon Cognito für authentifizierte Benutzer in Verified Permissions finden Sie unter [Authorization with Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) im *Amazon Cognito* Developer Guide.
# Amazon Cognito Identitätsquellen für Amazon Verified Permissions bearbeiten
Sie können einige Parameter Ihrer Identitätsquelle bearbeiten, nachdem Sie sie erstellt haben. Sie können den Typ der Identitätsquelle nicht ändern. Sie müssen die Identitätsquelle löschen und eine neue erstellen, um von OIDC oder OIDC Amazon Cognito zu wechseln. Amazon Cognito Wenn Ihr Richtlinienspeicher-Schema Ihren Identitätsquellenattributen entspricht, beachten Sie, dass Sie Ihr Schema separat aktualisieren müssen, um die Änderungen widerzuspiegeln, die Sie an Ihrer Identitätsquelle vornehmen.
------
#### [ AWS-Managementkonsole ]
**Um eine Amazon Cognito Identitätsquelle zu aktualisieren**
1. Öffnen Sie die [Konsole Verified Permissions](https://console.aws.amazon.com/verifiedpermissions/). Wählen Sie Ihren Richtlinienspeicher aus.
1. Wählen Sie im Navigationsbereich auf der linken Seite **Identitätsquellen aus**.
1. Wählen Sie die ID der Identitätsquelle aus, die Sie bearbeiten möchten.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie in den **Cognito-Benutzerpooldetails** die **Benutzerpool-ID** für Ihre Identitätsquelle aus AWS-Region und geben Sie sie ein.
1. In den **Prinzipaldetails** können Sie den **Prinzipaltyp** für die Identitätsquelle aktualisieren. Identitäten aus den verbundenen Amazon Cognito Cognito-Benutzerpools werden dem ausgewählten Prinzipaltyp zugeordnet.
1. Wählen Sie in der **Gruppenkonfiguration** die Option **Cognito-Gruppen verwenden** aus, wenn Sie den `cognito:groups` Benutzerpoolanspruch zuordnen möchten. Wählen Sie einen Entitätstyp, der dem Prinzipaltyp übergeordnet ist.
1. Wählen Sie unter **Validierung der Client-Anwendung** aus, ob die Client-Anwendung validiert werden soll IDs.
+ Um die Client-Anwendung zu validieren IDs, wählen Sie **Nur Tokens mit passender Client-Anwendung akzeptieren IDs**. Wählen Sie **Neue Client-Anwendungs-ID hinzufügen** für jede zu validierende Client-Anwendungs-ID aus. Um eine hinzugefügte Client-Anwendungs-ID zu **entfernen**, klicken Sie neben der Client-Anwendungs-ID auf Entfernen.
+ Wählen **Sie Client-Anwendung nicht validieren IDs**, wenn Sie die Client-Anwendung nicht validieren möchten IDs.
1. Wählen Sie **Änderungen speichern ** aus.
1. Wenn Sie den Prinzipaltyp für die Identitätsquelle geändert haben, müssen Sie Ihr Schema aktualisieren, damit es den aktualisierten Prinzipaltyp korrekt wiedergibt.
Sie können eine Identitätsquelle löschen, indem Sie das Optionsfeld neben einer Identitätsquelle auswählen und dann **Identitätsquelle löschen** auswählen. Geben Sie `delete` etwas in das Textfeld ein und wählen Sie dann **Identitätsquelle löschen** aus, um das Löschen der Identitätsquelle zu bestätigen.
------
#### [ AWS CLI ]
**Um eine Amazon Cognito Identitätsquelle zu aktualisieren**
Sie können eine Identitätsquelle aktualisieren, indem Sie den [UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)Vorgang verwenden. Im folgenden Beispiel wird die angegebene Identitätsquelle aktualisiert, sodass sie einen anderen Amazon Cognito Benutzerpool verwendet.
1. Erstellen Sie eine `config.txt` Datei, die die folgenden Details des Amazon Cognito Benutzerpools zur Verwendung durch den `--configuration` Parameter im `update-identity-source` Befehl enthält.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Führen Sie den folgenden Befehl aus, um eine Amazon Cognito Identitätsquelle zu aktualisieren.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**Anmerkung**
Wenn Sie den Prinzipaltyp für die Identitätsquelle ändern, müssen Sie Ihr Schema aktualisieren, damit es den aktualisierten Prinzipaltyp korrekt wiedergibt.
------
# Zuordnen von Amazon Cognito Tokens zum Schema
Möglicherweise möchten Sie einem Richtlinienspeicher eine Identitätsquelle hinzufügen und Anbieteransprüche oder Token Ihrem Richtlinienspeicherschema zuordnen. Sie können diesen Vorgang automatisieren, indem Sie den [geführten Einrichtungsvorgang](policy-stores-create.md) verwenden, um Ihren Richtlinienspeicher mit einer Identitätsquelle zu erstellen, oder Ihr Schema manuell aktualisieren, nachdem der Richtlinienspeicher erstellt wurde. Sobald Sie die Token dem Schema zugeordnet haben, können Sie Richtlinien erstellen, die auf sie verweisen.
Dieser Abschnitt des Benutzerhandbuchs enthält die folgenden Informationen:
+ Wann können Sie Attribute automatisch in ein Policy-Store-Schema eintragen
+ So verwenden Sie Amazon Cognito Token-Ansprüche in Ihren Richtlinien für verifizierte Berechtigungen
+ Wie erstelle ich manuell ein Schema für eine Identitätsquelle
[API-verknüpfte Richtlinienspeicher und Richtlinienspeicher](policy-stores-api-userpool.md) mit einer Identitätsquelle, die über die [geführte Installation](policy-stores-create.md) erstellt wurden, erfordern keine manuelle Zuordnung von Identitätstokenattributen (ID) zum Schema. Sie können den Attributen in Ihrem Benutzerpool verifizierte Berechtigungen zuordnen und ein Schema erstellen, das mit Benutzerattributen gefüllt ist. Bei der Autorisierung von ID-Tokens ordnet Verified Permissions Ansprüche Attributen einer Prinzipalentität zu. Unter den folgenden Bedingungen müssen Sie Ihrem Schema möglicherweise Amazon Cognito Token manuell zuordnen:
+ Sie haben einen leeren Richtlinienspeicher oder Richtlinienspeicher anhand eines Beispiels erstellt.
+ Sie möchten Ihre Verwendung von Zugriffstoken über die rollenbasierte Zugriffskontrolle (RBAC) hinaus erweitern.
+ Sie erstellen Richtlinienspeicher mit der REST-API für verifizierte Berechtigungen, einem AWS SDK oder dem. AWS CDK
Um es Amazon Cognito als Identitätsquelle in Ihrem Richtlinienspeicher für verifizierte Berechtigungen verwenden zu können, müssen Sie Anbieterattribute in Ihrem Schema haben. Das Schema ist fest und muss den Entitäten entsprechen, die Anbieter-Tokens in [IsAuthorizedWithToken[BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)API-Anfragen erstellen. Wenn Sie Ihren Richtlinienspeicher so erstellt haben, dass Ihr Schema automatisch anhand der Anbieterinformationen in einem ID-Token aufgefüllt wird, sind Sie bereit, Richtlinien zu schreiben. Wenn Sie einen Richtlinienspeicher ohne Schema für Ihre Identitätsquelle erstellen, müssen Sie dem Schema Anbieterattribute hinzufügen, die den mithilfe von API-Anfragen erstellten Entitäten entsprechen. Anschließend können Sie Richtlinien mithilfe von Attributen aus dem Anbietertoken schreiben.
Weitere Informationen zur Verwendung von Amazon Cognito ID und Zugriffstoken für authentifizierte Benutzer in Verified Permissions finden Sie unter [Authorization with Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) im *Amazon Cognito* Developer Guide.
**Topics**
+ [Zuordnen von ID-Token zum Schema](#cognito-map-id-token)
+ [Zugriffstoken zuordnen](#cognito-map-access-token)
+ [Alternative Schreibweise für durch Amazon Cognito Doppelpunkte getrennte Ansprüche](#cognito-colon-claims)
+ [Wissenswertes über Schema-Mapping](#cognito-map-token-to-schema-things-to-know)
## Zuordnen von ID-Token zum Schema
Verified Permissions verarbeitet ID-Token-Ansprüche als Attribute des Benutzers: seine Namen und Titel, seine Gruppenzugehörigkeit, seine Kontaktinformationen. ID-Token sind in einem ABAC-Autorisierungsmodell (*attribute-based access control*) am nützlichsten. Wenn Sie möchten, dass Verified Permissions den Zugriff auf Ressourcen basierend darauf analysiert, wer die Anfrage stellt, wählen Sie ID-Token als Identitätsquelle.
Amazon Cognito ID-Token funktionieren mit den meisten [OIDC-Rely-Party-Bibliotheken](https://openid.net/developers/certified-openid-connect-implementations/). Sie erweitern die Funktionen von OIDC um zusätzliche Ansprüche. Ihre Anwendung kann den Benutzer mit den API-Operationen zur Authentifizierung von Amazon Cognito Cognito-Benutzerpools oder mit der gehosteten Benutzerpool-Benutzeroberfläche authentifizieren. *Weitere Informationen finden Sie unter [Verwenden der API und der Endgeräte im Amazon Cognito Entwicklerhandbuch](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html).*Nützliche Angaben in Amazon Cognito ID-Tokens
*`cognito:username` und `preferred_username`*
Varianten des Benutzernamens.
*`sub`*
Die eindeutige Benutzerkennung (UUID) des Benutzers
*Ansprüche mit einem Präfix `custom:`*
Ein Präfix für benutzerdefinierte Benutzerpool-Attribute wie`custom:employmentStoreCode`.
*Standardansprüche*
Standardansprüche von OIDC wie `email` und. `phone_number` Weitere Informationen finden Sie unter [Standardansprüche](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) in *OpenID Connect Core 1.0, in denen Errata Set 2 enthalten* ist.
*`cognito:groups`*
Die Gruppenmitgliedschaften eines Benutzers. In einem Autorisierungsmodell, das auf der rollenbasierten Zugriffskontrolle (RBAC) basiert, stellt dieser Anspruch die Rollen dar, die Sie in Ihren Richtlinien bewerten können.
*Vorübergehende Ansprüche*
Ansprüche, die nicht Eigentum des Benutzers sind, aber zur Laufzeit durch einen [Lambda-Trigger vor der Token-Generierung](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) aus dem Benutzerpool hinzugefügt werden. Vorübergehende Ansprüche ähneln Standardansprüchen, liegen aber außerhalb des Standards, z. B. `tenant` oder. `department`
In Richtlinien, die auf Amazon Cognito Attribute verweisen, die über ein `:` Trennzeichen verfügen, verweisen Sie auf die Attribute im Format`principal["cognito:username"]`. Der Rollenanspruch `cognito:groups` stellt eine Ausnahme von dieser Regel dar. Verified Permissions ordnet den Inhalt dieses Anspruchs den übergeordneten Entitäten der Benutzerentität zu.
Weitere Informationen zur Struktur von ID-Tokens aus Amazon Cognito Cognito-Benutzerpools finden Sie unter [Verwenden des ID-Tokens](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) im *Amazon Cognito Entwicklerhandbuch*.
Das folgende Beispiel für ein ID-Token hat jeden der vier Attributtypen. Es umfasst den Amazon Cognito spezifischen Anspruch`cognito:username`, den benutzerdefinierten Anspruch`custom:employmentStoreCode`, den Standardanspruch `email` und den vorübergehenden Anspruch. `tenant`
```
{
"sub": "91eb4550-XXX",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"email_verified": true,
"clearance": "confidential",
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"cognito:username": "alice",
"custom:employmentStoreCode": "petstore-dallas",
"origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77",
"aud": "1example23456789",
"event_id": "0ed5ad5c-7182-4ecf-XXX",
"token_use": "id",
"auth_time": 1687885407,
"department": "engineering",
"exp": 1687889006,
"iat": 1687885407,
"tenant": "x11app-tenant-1",
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"email": "alice@example.com"
}
```
Wenn Sie mit Ihrem Amazon Cognito Benutzerpool eine Identitätsquelle erstellen, geben Sie den Typ der Prinzipalentität an, mit der Verified Permissions in Autorisierungsanfragen generiert. `IsAuthorizedWithToken` Ihre Richtlinien können dann im Rahmen der Bewertung dieser Anfrage die Attribute dieses Prinzipals testen. Ihr Schema definiert den Prinzipaltyp und die Attribute für eine Identitätsquelle, und dann können Sie in Ihren Cedar-Richtlinien darauf verweisen.
Sie geben auch den Typ der Gruppenentität an, den Sie aus dem Anspruch der ID-Token-Gruppen ableiten möchten. In Autorisierungsanfragen ordnet Verified Permissions jedes Mitglied des Gruppenanspruchs diesem Gruppen-Entitätstyp zu. In Richtlinien können Sie auf diese Gruppenentität als Principal verweisen.
Das folgende Beispiel zeigt, wie Sie die Attribute aus dem Beispiel-Identitätstoken in Ihrem Verified Permissions-Schema wiedergeben können. Weitere Informationen zur Bearbeitung Ihres Schemas finden Sie unter[Policy-Store-Schemas bearbeiten](schema-edit.md). Wenn Ihre Identitätsquellenkonfiguration den Prinzipaltyp angibt`User`, können Sie etwas Ähnliches wie das folgende Beispiel hinzufügen, um diese Attribute für Cedar verfügbar zu machen.
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": false
},
"custom:employmentStoreCode": {
"type": "String",
"required": false
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Ein Beispiel für eine Richtlinie, die anhand dieses Schemas validiert wird, finden Sie unter[Spiegelt Amazon Cognito ID-Token-Attribute wider](policies-examples.md#policies-examples-cognito-id).
## Zugriffstoken zuordnen
Verified Permissions verarbeitet Ansprüche auf Zugriffstoken, die nicht von Gruppen als Attribute der Aktion oder als *Kontext-Attribute* beansprucht werden. Neben der Gruppenmitgliedschaft können die Zugriffstoken Ihres IdP Informationen über den API-Zugriff enthalten. Zugriffstoken sind in Autorisierungsmodellen nützlich, die eine rollenbasierte Zugriffskontrolle (RBAC) verwenden. Autorisierungsmodelle, die auf anderen Zugriffstoken-Ansprüchen als der Gruppenmitgliedschaft basieren, erfordern zusätzlichen Aufwand bei der Schemakonfiguration.
Amazon Cognito Zugriffstoken haben Ansprüche, die für die Autorisierung verwendet werden können:Nützliche Angaben in Amazon Cognito Zugriffstoken
*`client_id`*
Die ID der Client-Anwendung einer vertrauenden OIDC-Partei. Anhand der Client-ID kann Verified Permissions überprüfen, ob die Autorisierungsanfrage von einem autorisierten Client für den Richtlinienspeicher stammt. Bei der machine-to-machine (M2M-) Autorisierung autorisiert das anfordernde System eine Anfrage mit einem geheimen Client-Schlüssel und stellt die Client-ID und den Geltungsbereich als Autorisierungsnachweis zur Verfügung.
*`scope`*
Die [OAuth 2.0-Bereiche](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3), die die Zugriffsberechtigungen des Inhabers des Tokens darstellen.
*`cognito:groups`*
Die Gruppenmitgliedschaften eines Benutzers. In einem Autorisierungsmodell, das auf der rollenbasierten Zugriffskontrolle (RBAC) basiert, stellt dieser Anspruch die Rollen dar, die Sie in Ihren Richtlinien bewerten können.
*Vorübergehende Ansprüche*
Ansprüche, bei denen es sich nicht um eine Zugriffsberechtigung handelt, die aber zur Laufzeit durch einen [Lambda-Trigger vor der Token-Generierung](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) im Benutzerpool hinzugefügt werden. Vorübergehende Ansprüche ähneln Standardansprüchen, liegen aber außerhalb des Standards, z. B. `tenant` oder. `department` Die Anpassung von Zugriffstoken erhöht Ihre AWS Rechnung um zusätzliche Kosten.
Weitere Informationen zur Struktur von Zugriffstoken aus Amazon Cognito Cognito-Benutzerpools finden Sie unter [Verwenden des Zugriffstokens](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) im *Amazon Cognito Entwicklerhandbuch*.
Ein Amazon Cognito Zugriffstoken wird einem Kontextobjekt zugeordnet, wenn es an Verified Permissions übergeben wird. Auf Attribute des Zugriffstokens kann mit `context.token.attribute_name` verwiesen werden. Das folgende Beispiel für ein Zugriffstoken umfasst `client_id` sowohl die `scope` Ansprüche als auch.
```
{
"sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"client_id": "1example23456789",
"origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011",
"token_use": "access",
"scope": "MyAPI/mydata.write",
"auth_time": 1688092966,
"exp": 1688096566,
"iat": 1688092966,
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
"username": "alice"
}
```
Das folgende Beispiel zeigt, wie Sie die Attribute aus dem Beispielzugriffstoken in Ihrem Verified Permissions-Schema wiedergeben können. Weitere Informationen zur Bearbeitung Ihres Schemas finden Sie unter[Policy-Store-Schemas bearbeiten](schema-edit.md).
```
{
"MyApplication": {
"actions": {
"Read": {
"appliesTo": {
"context": {
"type": "ReusedContext"
},
"resourceTypes": [
"Application"
],
"principalTypes": [
"User"
]
}
}
},
...
...
"commonTypes": {
"ReusedContext": {
"attributes": {
"token": {
"type": "Record",
"attributes": {
"scope": {
"type": "Set",
"element": {
"type": "String"
}
},
"client_id": {
"type": "String"
}
}
}
},
"type": "Record"
}
}
}
}
```
Ein Beispiel für eine Richtlinie, die anhand dieses Schemas validiert wird, finden Sie unter[Spiegelt Attribute von Amazon Cognito Zugriffstoken wider](policies-examples.md#policies-examples-cognito-access).
## Alternative Schreibweise für durch Amazon Cognito Doppelpunkte getrennte Ansprüche
Zu dem Zeitpunkt, als Verified Permissions gestartet wurde, beanspruchte das empfohlene Schema für Amazon Cognito Token diese durch Doppelpunkte getrennten Zeichenketten `cognito:groups` und `custom:store` konvertierte sie so, dass sie das Zeichen als Hierarchie-Trennzeichen verwenden. `.` *Dieses Format wird als Punktnotation bezeichnet.* Beispielsweise `cognito:groups` wurde `principal.cognito.groups` in Ihren Richtlinien ein Verweis auf aufgenommen. Sie können dieses Format zwar weiterhin verwenden, wir empfehlen Ihnen jedoch, Ihr Schema und Ihre Richtlinien in [Klammern zu erstellen](#cognito-map-token-to-schema-things-to-know). In diesem Format `cognito:groups` wird ein Verweis auf `principal["cognito:groups"]` in Ihren Richtlinien enthalten. Automatisch generierte Schemas für Benutzerpool-ID-Token aus der Verified Permissions-Konsole verwenden Klammern.
In manuell erstellten Schemas und Richtlinien für Identitätsquellen können Sie weiterhin die Punktnotation verwenden. Amazon Cognito Sie können die Punktnotation mit `:` oder anderen nicht alphanumerischen Zeichen in Schemas oder Richtlinien für keinen anderen Typ von OIDC-IdP verwenden.
Ein Schema für die Punktnotation verschachtelt jede Instanz eines `:` Zeichens als untergeordnetes Element der `cognito` oder `custom` ersten Phrase, wie im folgenden Beispiel gezeigt:
```
"CognitoUser": {
"shape": {
"type": "Record",
"attributes": {
"cognito": {
"type": "Record",
"required": true,
"attributes": {
"username": {
"type": "String",
"required": true
}
}
},
"custom": {
"type": "Record",
"required": true,
"attributes": {
"employmentStoreCode": {
"type": "String",
"required": true
}
}
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Ein Beispiel für eine Richtlinie, die anhand dieses Schemas validiert und die Punktnotation verwendet, finden Sie unter[Verwendet Punktnotation, um auf Attribute zu verweisen](policies-examples.md#policies-examples-dot).
## Wissenswertes über Schema-Mapping
**Die Attributzuweisung unterscheidet sich je nach Token-Typ**
Bei der Autorisierung von Zugriffstoken ordnet Verified Permissions Ansprüche dem [Kontext](context.md) zu. Bei der Autorisierung von ID-Tokens ordnet Verified Permissions Ansprüche den Hauptattributen zu. Bei Richtlinienspeichern, die Sie in der Verified Permissions-Konsole erstellen, haben Sie nur **leere** Richtlinienspeicher und **Beispiel-Richtlinienspeicher**, sodass Sie keine Identitätsquelle haben und Sie Ihr Schema mit Benutzerpool-Attributen für die ID-Token-Autorisierung auffüllen müssen. Die Autorisierung mit Zugriffstoken basiert auf der rollenbasierten Zugriffskontrolle (RBAC) mit Gruppenmitgliedschaftsansprüchen und ordnet andere Ansprüche nicht automatisch dem Richtlinienspeicherschema zu.
**Identitätsquellenattribute sind nicht erforderlich**
Wenn Sie in der Konsole „Verified Permissions“ eine Identitätsquelle erstellen, werden keine Attribute als erforderlich markiert. Dadurch wird verhindert, dass fehlende Ansprüche zu Validierungsfehlern bei Autorisierungsanfragen führen. Sie können Attribute nach Bedarf auf erforderlich setzen, sie müssen jedoch in allen Autorisierungsanfragen vorhanden sein.
**RBAC benötigt keine Attribute im Schema**
Schemas für Identitätsquellen hängen von den Entitätszuordnungen ab, die Sie beim Hinzufügen Ihrer Identitätsquelle vornehmen. Eine Identitätsquelle ordnet einen Anspruch einem Benutzerentiätstyp und einen Anspruch einem Gruppen-Entitätstyp zu. Diese Entitätszuordnungen sind der Kern einer Identitätsquellenkonfiguration. Mit diesen Mindestinformationen können Sie Richtlinien schreiben, die Autorisierungsaktionen für bestimmte Benutzer und bestimmte Gruppen, denen Benutzer möglicherweise angehören, in einem Modell der rollenbasierten Zugriffskontrolle (RBAC) ausführen. Durch das Hinzufügen von Token-Ansprüchen zum Schema wird der Autorisierungsbereich Ihres Richtlinienspeichers erweitert. Benutzerattribute aus ID-Tokens enthalten Informationen über Benutzer, die zur ABAC-Autorisierung (attribute-Based Access Control) beitragen können. Kontextattribute von Zugriffstoken enthalten Informationen wie OAuth 2.0-Bereiche, die zusätzliche Informationen zur Zugriffskontrolle von Ihrem Anbieter bereitstellen können, aber zusätzliche Schemaänderungen erfordern.
Die Optionen **Mit API Gateway und einem Identitätsanbieter einrichten** und **Geführte Einrichtung** in der Konsole Verified Permissions weisen dem Schema ID-Token-Ansprüche zu. Dies ist bei Ansprüchen auf Zugriffstoken nicht der Fall. [Um Ihrem Schema Ansprüche auf Zugriffstoken hinzuzufügen, die nicht zu Gruppen gehören, müssen Sie Ihr Schema im JSON-Modus bearbeiten und CommonTypes-Attribute hinzufügen.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Weitere Informationen finden Sie unter [Zugriffstoken zuordnen](#cognito-map-access-token).
**Wählen Sie einen Tokentyp**
Wie Ihr Richtlinienspeicher mit Ihrer Identitätsquelle zusammenarbeitet, hängt von einer wichtigen Entscheidung bei der Konfiguration der Identitätsquelle ab: ob Sie ID- oder Zugriffstoken verarbeiten. Bei einem Amazon Cognito Identitätsanbieter haben Sie die Wahl zwischen dem Tokentyp, wenn Sie einen API-verknüpften Richtlinienspeicher erstellen. Wenn Sie einen [API-verknüpften Richtlinienspeicher](policy-stores-api-userpool.md) erstellen, müssen Sie auswählen, ob Sie die Autorisierung für ID- oder Zugriffstoken einrichten möchten. Diese Informationen wirken sich auf die Schemaattribute aus, die Verified Permissions auf Ihren Richtlinienspeicher anwendet, und auf die Syntax des Lambda-Autorisierers für Ihre API Gateway API. Insbesondere, wenn Sie von der automatischen Zuordnung von ID-Token-Ansprüchen zu Attributen in der Verified Permissions-Konsole profitieren möchten, entscheiden Sie sich frühzeitig für den Tokentyp, den Sie verarbeiten möchten, bevor Sie Ihre Identitätsquelle erstellen. Das Ändern des Tokentyps erfordert einen erheblichen Aufwand, um Ihre Richtlinien und Ihr Schema umzugestalten. In den folgenden Themen wird die Verwendung von ID- und Zugriffstoken mit Richtlinienspeichern beschrieben.
**Der Cedar-Parser benötigt für einige Zeichen Klammern**
Richtlinien verweisen normalerweise auf Schemaattribute in einem Format wie`principal.username`. Bei den meisten nicht-alphanumerischen Zeichen wie`:`, oder`.`, `/` die in Namen von Token-Ansprüchen vorkommen können, kann Verified Permissions einen Bedingungswert wie oder nicht analysieren. `principal.cognito:username` `context.ip-address` Stattdessen müssen Sie diese Bedingungen mit Klammernotation im jeweiligen Format `principal["cognito:username"]` oder `context["ip-address"]` formatieren. Der Unterstrich `_` ist ein gültiges Zeichen in Anspruchsnamen und die einzige Ausnahme von dieser Anforderung, die nicht alphanumerisch ist.
Ein teilweises Beispielschema für ein Hauptattribut dieses Typs sieht wie folgt aus:
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": true
},
"custom:employmentStoreCode": {
"type": "String",
"required": true,
},
"email": {
"type": "String",
"required": false
}
}
}
}
```
Ein teilweises Beispielschema für ein Kontextattribut dieses Typs sieht wie folgt aus:
```
"GetOrder": {
"memberOf": [],
"appliesTo": {
"resourceTypes": [
"Order"
],
"context": {
"type": "Record",
"attributes": {
"ip-address": {
"required": false,
"type": "String"
}
}
},
"principalTypes": [
"User"
]
}
}
```
Ein Beispiel für eine Richtlinie, die anhand dieses Schemas validiert wird, finden Sie unter[Verwendet die Klammernotation, um auf Token-Attribute zu verweisen](policies-examples.md#policies-examples-brackets).
# Kunden- und Zielgruppenvalidierung für Amazon Cognito
Wenn Sie einem Richtlinienspeicher eine Identitätsquelle hinzufügen, verfügt Verified Permissions über Konfigurationsoptionen, mit denen überprüft wird, ob ID und Zugriffstoken wie vorgesehen verwendet werden. Diese Überprüfung erfolgt bei der Verarbeitung von `IsAuthorizedWithToken` und `BatchIsAuthorizedWithToken` API-Anfragen. Das Verhalten unterscheidet sich zwischen ID- und Zugriffstoken Amazon Cognito sowie zwischen OIDC-Identitätsquellen. Bei Anbietern von Amazon Cognito Cognito-Benutzerpools kann Verified Permissions die Client-ID sowohl in ID- als auch in Zugriffstoken validieren. Bei OIDC-Anbietern kann Verified Permissions die Client-ID in ID-Token und die Zielgruppe in Zugriffstoken validieren.
Eine *Client-ID* ist eine Kennung, die beispielsweise der Identitätsanbieter-Instanz zugeordnet ist, die Ihre Anwendung verwendet. `1example23456789` Eine *Zielgruppe* ist beispielsweise ein URL-Pfad, der der *vertrauenden Partei* oder dem Ziel des Zugriffstokens zugeordnet ist`https://mytoken.example.com`. Bei der Verwendung von Zugriffstoken ist der `aud` Anspruch immer mit der Zielgruppe verknüpft.
Amazon Cognito ID-Token haben einen `aud` Anspruch, der die [App-Client-ID](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html) enthält. Zugriffstoken haben einen `client_id` Anspruch, der auch die App-Client-ID enthält.
Wenn Sie in Ihrer Identitätsquelle einen oder mehrere Werte für die **Validierung von Client-Anwendungen** eingeben, vergleicht Verified Permissions diese Liste von App-Clients IDs mit dem `aud` ID-Token-Anspruch oder dem `client_id` Zugriffstoken-Anspruch. Verified Permissions validiert keine Zielgruppen-URL einer vertrauenden Partei für Amazon Cognito Identitätsquellen.
## Clientseitige Autorisierung für JWTs
Möglicherweise möchten Sie JSON-Webtoken in Ihrer Anwendung verarbeiten und deren Ansprüche an Verified Permissions weiterleiten, ohne eine Identitätsquelle für den Richtlinienspeicher zu verwenden. Sie können Ihre Entitätsattribute aus einem JSON Web Token (JWT) extrahieren und in verifizierte Berechtigungen umwandeln.
Dieses Beispiel zeigt, wie Sie verifizierte Berechtigungen von einer Anwendung aus aufrufen könnten, die ein JWT verwendet¹.
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ In diesem Codebeispiel wird die [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)Bibliothek zur Überprüfung JWTs verwendet, die mit OIDC-kompatibel signiert wurde. IdPs