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.
# Schützen Sie Ihre Anwendungen mit Identitätsquellen und Tokens
Schützen Sie Ihre Anwendungen schnell, indem Sie eine *Identitätsquelle* erstellen, die einen externen Identitätsanbieter (IdP) in Amazon Verified Permissions repräsentiert. Identitätsquellen stellen Informationen von einem Benutzer bereit, der sich bei einem IdP authentifiziert hat, der eine Vertrauensbeziehung zu Ihrem Richtlinienspeicher unterhält. Wenn Ihre Anwendung eine Autorisierungsanfrage mit einem Token aus einer Identitätsquelle stellt, kann Ihr Richtlinienspeicher anhand von Benutzereigenschaften und Zugriffsberechtigungen Autorisierungsentscheidungen treffen. Sie können einen Amazon Cognito Cognito-Benutzerpool oder einen benutzerdefinierten OpenID Connect (OIDC) IdP als Identitätsquelle hinzufügen.
Sie können [OpenID Connect (OIDC) -Identitätsanbieter (IdPs)](https://openid.net/specs/openid-connect-core-1_0.html) mit verifizierten Berechtigungen verwenden. Ihre Anwendung kann Autorisierungsanfragen mit JSON-Webtoken (JWTs) generieren, die von einem OIDC-konformen Identitätsanbieter generiert wurden. Die Benutzeridentität im Token ist der Prinzipal-ID zugeordnet. Bei ID-Tokens ordnet Verified Permissions Attributansprüche den Hauptattributen zu. Mit Zugriffstoken werden diese Ansprüche dem [Kontext](context.md) zugeordnet. Mit beiden Tokentypen können Sie einen Anspruch quasi einer Prinzipalgruppe `groups` zuordnen und Richtlinien erstellen, die die rollenbasierte Zugriffskontrolle (RBAC) bewerten.
**Anmerkung**
Verified Permissions trifft Autorisierungsentscheidungen auf der Grundlage von Informationen aus einem IdP-Token, interagiert jedoch in keiner Weise direkt mit dem IdP.
*Eine step-by-step exemplarische Vorgehensweise, die die Autorisierungslogik für Amazon API Gateway REST APIs mithilfe eines Amazon Cognito Benutzerpools oder eines OIDC-Identitätsanbieters erstellt, finden Sie im Sicherheitsblog unter [Autorisieren API Gateway APIs mit Amazon Verified Permissions with Amazon Cognito or Bring Your Own Identity Provider](https://aws.amazon.com/blogs/security/authorize-api-gateway-apis-using-amazon-verified-permissions-and-amazon-cognito/).AWS *
**Topics**
+ [Den richtigen Identitätsanbieter auswählen](#choosing-identity-source)
+ [Arbeiten mit Amazon Cognito Identitätsquellen](identity-sources-cognito.md)
+ [Arbeiten mit OIDC-Identitätsquellen](identity-sources-oidc.md)
## Den richtigen Identitätsanbieter auswählen
Verified Permissions funktioniert zwar mit einer Vielzahl von Berechtigungen IdPs, Sie sollten jedoch Folgendes berücksichtigen, wenn Sie entscheiden, welche Berechtigungen Sie in Ihrer Anwendung verwenden möchten:
Verwenden Sie Amazon Cognito es, wenn:
+ Sie entwickeln neue Anwendungen ohne bestehende Identitätsinfrastruktur
+ Sie möchten AWS verwaltete Benutzerpools mit integrierten Sicherheitsfunktionen
+ Sie benötigen die Integration eines Anbieters für soziale Identitäten
+ Sie möchten eine vereinfachte Tokenverwaltung
Verwenden Sie OIDC-Anbieter, wenn:
+ Sie verfügen über eine bestehende Identitätsinfrastruktur (Auth0, Okta, Azure AD)
+ Sie müssen eine zentralisierte Benutzerverwaltung aufrechterhalten
+ Sie haben Compliance-Anforderungen für bestimmte IdPs
# 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
# Arbeiten mit OIDC-Identitätsquellen
Sie können auch jeden kompatiblen OpenID Connect (OIDC) IdP als Identitätsquelle für einen Richtlinienspeicher konfigurieren. OIDC-Anbieter ähneln Amazon Cognito Cognito-Benutzerpools: Sie produzieren JWTs als Produkt der Authentifizierung. Um einen OIDC-Anbieter hinzuzufügen, müssen Sie eine Aussteller-URL angeben
Für eine neue OIDC-Identitätsquelle sind die folgenden Informationen erforderlich:
+ Die URL des Ausstellers. Verifizierte Berechtigungen müssen in der Lage sein, einen `.well-known/openid-configuration` Endpunkt unter dieser URL zu erkennen.
+ CNAME-Einträge, die keine Platzhalter enthalten. `a.example.com`Kann beispielsweise nicht zugeordnet werden. `*.example.net` Umgekehrt `*.example.com` kann nicht zugeordnet werden. `a.example.net`
+ Der Tokentyp, den Sie in Autorisierungsanfragen verwenden möchten. In diesem Fall haben Sie **Identitätstoken** gewählt.
+ Der Benutzer-Entitätstyp, den Sie Ihrer Identitätsquelle zuordnen möchten, zum Beispiel`MyCorp::User`.
+ Zum Beispiel der Gruppen-Entitätstyp, den Sie Ihrer Identitätsquelle zuordnen möchten`MyCorp::UserGroup`.
+ Ein Beispiel für ein ID-Token oder eine Definition der Ansprüche im ID-Token.
+ Das Präfix, das Sie auf die Benutzer- und Gruppenentität anwenden möchten IDs. In der CLI und API können Sie dieses Präfix wählen. In Richtlinienspeichern, die Sie mit der Option **Mit API Gateway und einem Identitätsanbieter einrichten** oder **Geführte Einrichtung** erstellen, weist Verified Permissions beispielsweise ein Präfix mit dem Namen des Ausstellers minus `https://` zu. `MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`
Weitere Informationen zur Verwendung von API-Vorgängen zur Autorisierung von Anfragen aus OIDC-Quellen finden Sie unter. [Verfügbare API-Operationen für die Autorisierung](authorization.md#authorization-operations)
Das folgende Beispiel zeigt, wie Sie eine Richtlinie erstellen könnten, die Mitarbeitern der Buchhaltungsabteilung Zugriff auf Jahresabschlussberichte gewährt, die vertraulich eingestuft sind und sich nicht in einem Außenbüro befinden. Verified Permissions leitet diese Attribute aus den Ansprüchen im ID-Token des Prinzipals ab.
Beachten Sie, dass Sie beim Verweisen auf eine Gruppe im Prinzipal den `in` Operator verwenden müssen, damit die Richtlinie korrekt ausgewertet wird.
```
permit(
principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting",
action,
resource in MyCorp::Folder::"YearEnd2024"
) when {
principal.jobClassification == "Confidential" &&
!(principal.location like "SatelliteOffice*")
};
```
**Topics**
+ [OIDC-Identitätsquellen mit Amazon Verified Permissions erstellen](oidc-create.md)
+ [Bearbeiten von OIDC-Identitätsquellen mit Amazon Verified Permissions](oidc-edit.md)
+ [Zuordnung von OIDC-Token zum Schema](oidc-map-token-to-schema.md)
+ [Kunden- und Zielgruppenvalidierung für OIDC-Anbieter](oidc-validation.md)
# OIDC-Identitätsquellen mit 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 OpenID Connect (OIDC) -Identitätsquelle**
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 **Externer OIDC-Anbieter**.
1. Geben Sie im Feld **Aussteller-URL** die URL Ihres OIDC-Ausstellers ein. Dies ist der Dienstendpunkt, der beispielsweise den Autorisierungsserver, Signaturschlüssel und andere Informationen über Ihren Anbieter bereitstellt. `https://auth.example.com` Ihre Aussteller-URL muss ein OIDC-Discovery-Dokument unter hosten. `/.well-known/openid-configuration`
1. Wählen Sie unter **Tokentyp** den Typ des OIDC JWT aus, den Ihre Anwendung zur Autorisierung einreichen soll. Weitere Informationen finden Sie unter [Zuordnung von OIDC-Token zum Schema](oidc-map-token-to-schema.md).
1. Wählen Sie **unter Tokenansprüche Schemaentitäten** zuordnen eine **Benutzerentität und **Benutzeranspruch**** für die Identitätsquelle aus. Die **Benutzerentität** ist eine Entität in Ihrem Richtlinienspeicher, auf die Sie auf Benutzer Ihres OIDC-Anbieters verweisen möchten. Bei dem **Benutzeranspruch** handelt es sich in der Regel `sub` um einen Anspruch aus Ihrer ID oder Ihrem Zugriffstoken, das die eindeutige Kennung für die zu bewertende Entität enthält. Identitäten des verbundenen OIDC-IdP werden dem ausgewählten Prinzipaltyp zugeordnet.
1. (Optional) Wählen Sie unter **Tokenansprüche Schemaentitäten zuordnen** eine **Gruppenentität und einen **Gruppenanspruch**** als Identitätsquelle aus. Die **Gruppenentität** ist der **Benutzerentität [übergeordnet](https://docs.cedarpolicy.com/overview/terminology.html#term-group)**. Gruppenansprüche werden dieser Entität zugeordnet. Bei dem **Gruppenanspruch** handelt es sich in der Regel `groups` um einen Anspruch aus Ihrer ID oder Ihrem Zugriffstoken, der eine Zeichenfolge, JSON oder eine durch Leerzeichen getrennte Zeichenfolge mit Benutzergruppennamen für die auszuwertende Entität enthält. Identitäten des verbundenen OIDC-IdP werden dem ausgewählten Prinzipaltyp zugeordnet.
1. Geben Sie im Feld **Validierung — optional** den Kunden IDs oder die Zielgruppe ein URLs , die Ihr Richtlinienspeicher gegebenenfalls in Autorisierungsanfragen akzeptieren soll.
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 OIDC-Tokenattributen zu Cedar-Prinzipalattributen finden Sie unter. [Zuordnung von OIDC-Token zum Schema](oidc-map-token-to-schema.md)
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 ]
**Um eine OIDC-Identitätsquelle zu erstellen**
Sie können eine Identitätsquelle erstellen, indem Sie den [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)Vorgang verwenden. Im folgenden Beispiel wird eine Identitätsquelle erstellt, die auf authentifizierte Identitäten von einem OIDC-Identitätsanbieter (IdP) zugreifen kann.
1. Erstellen Sie eine `config.txt` Datei, die die folgenden Details eines OIDC-IdP zur Verwendung durch den `--configuration` Parameter des Befehls enthält. `create-identity-source`
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["1example23456789"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Führen Sie den folgenden Befehl aus, um eine OIDC-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 den Prinzipaltyp erkennt, den 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 OIDC-Tokenattributen zu Cedar-Prinzipalattributen finden Sie unter. [Zuordnung von OIDC-Token zum Schema](oidc-map-token-to-schema.md)
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*.
------
# Bearbeiten von OIDC-Identitätsquellen mit Amazon Verified Permissions
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 OIDC-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. Ändern Sie in den **OIDC-Anbieterdetails** die **Aussteller-URL** nach Bedarf.
1. Ändern Sie **unter Tokenansprüche den Schemaattributen** zuordnen die Verknüpfungen zwischen Benutzer- und Gruppenansprüchen und den Entitätstypen des Richtlinienspeichers nach Bedarf. Nachdem Sie die Entitätstypen geändert haben, müssen Sie Ihre Richtlinien und Schemaattribute aktualisieren, damit sie für die neuen Entitätstypen gelten.
1. Fügen Sie in der **Zielgruppenvalidierung** Zielgruppenwerte hinzu oder entfernen Sie sie, die Sie erzwingen möchten.
1. Wählen Sie **Änderungen speichern ** aus.
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 OIDC-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 OIDC-Anbieter verwendet.
1. Erstellen Sie eine `config.txt` Datei, die die folgenden Details eines OIDC-IdP zur Verwendung durch den `--configuration` Parameter des Befehls enthält. `update-identity-source`
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth2.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["2example10111213"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Führen Sie den folgenden Befehl aus, um eine OIDC-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.
------
# Zuordnung von OIDC-Token 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
+ Wie erstellt man 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 mit ID-Tokens ordnet Verified Permissions Ansprüche Attributen einer Prinzipalentität zu.
Um einen OIDC-Identitätsanbieter (IdP) als Identitätsquelle in Ihrem Richtlinienspeicher für verifizierte Berechtigungen zu verwenden, müssen Sie Anbieterattribute in Ihrem Schema haben. Das Schema ist fest und muss den Entitäten entsprechen, die Anbieter-Token in [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)API-Anfragen erstellen. [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html) 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.
**Topics**
+ [Zuordnen von ID-Token zum Schema](#oidc-map-id-token)
+ [Zugriffstoken zuordnen](#oidc-map-access-token)
+ [Wissenswertes über Schema-Mapping](#oidc-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.
Die Arbeit mit ID-Token von einem OIDC-Anbieter entspricht weitgehend der Arbeit mit Amazon Cognito ID-Token. Der Unterschied liegt in den Behauptungen. Ihr IdP kann [Standard-OIDC-Attribute](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) oder ein benutzerdefiniertes Schema aufweisen. Wenn Sie in der Konsole „Verified Permissions“ einen neuen Richtlinienspeicher erstellen, können Sie eine OIDC-Identitätsquelle mit einem Beispiel-ID-Token hinzufügen oder Tokenansprüche manuell Benutzerattributen zuordnen. Da Verified Permissions das Attributschema Ihres IdP nicht kennt, müssen Sie diese Informationen angeben.
Weitere Informationen finden Sie unter [Richtlinienspeicher für verifizierte Berechtigungen erstellen](policy-stores-create.md).
Im Folgenden finden Sie ein Beispielschema für einen Richtlinienspeicher mit einer OIDC-Identitätsquelle.
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"email": {
"type": "String"
},
"email_verified": {
"type": "Boolean"
},
"name": {
"type": "String",
"required": true
},
"phone_number": {
"type": "String"
},
"phone_number_verified": {
"type": "Boolean"
}
}
}
}
```
Ein Beispiel für eine Richtlinie, die anhand dieses Schemas validiert wird, finden Sie unter. [Spiegelt die Attribute von OIDC-ID-Tokens wider](policies-examples.md#policies-examples-oidc-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.
Die meisten Zugriffstoken von externen OIDC-Anbietern stimmen eng mit Zugriffstoken überein. Amazon Cognito Ein OIDC-Zugriffstoken wird einem Kontextobjekt zugeordnet, wenn es an Verified Permissions übergeben wird. Auf Attribute des Zugriffstokens kann mit verwiesen werden. `context.token.attribute_name` Das folgende Beispiel für ein OIDC-Zugriffstoken enthält Beispiele für Basisansprüche.
```
{
"sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
"groups": [
"Store-Owner-Role",
"Customer"
],
"iss": "https://auth.example.com",
"client_id": "1example23456789",
"aud": "https://myapplication.example.com"
"scope": "MyAPI-Read",
"exp": 1688096566,
"iat": 1688092966,
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
"username": "alice"
}
```
Das folgende Beispiel zeigt, wie Sie die Attribute aus dem Beispiel-Zugriffstoken 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 die Attribute von OIDC-Zugriffstoken wider](policies-examples.md#policies-examples-oidc-access).
## 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](#oidc-map-access-token).
**OIDC-Gruppen behaupten, dass mehrere Formate unterstützt werden**
Wenn Sie einen OIDC-Anbieter hinzufügen, können Sie den Namen des Gruppenanspruchs in ID- oder Zugriffstoken auswählen, den Sie der Gruppenmitgliedschaft eines Benutzers in Ihrem Richtlinienspeicher zuordnen möchten. Verifizierte Berechtigungen erkennen Gruppenansprüche in den folgenden Formaten an:
1. Zeichenfolge ohne Leerzeichen: `"groups": "MyGroup"`
1. Durch Leerzeichen getrennte Liste:. `"groups": "MyGroup1 MyGroup2 MyGroup3"` Jede Zeichenfolge ist eine Gruppe.
1. JSON-Liste (durch Kommas getrennt): `"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]`
**Anmerkung**
Verified Permissions interpretiert jede Zeichenfolge in einem durch Leerzeichen getrennten Gruppenanspruch als separate Gruppe. Um einen Gruppennamen mit einem Leerzeichen als einzelne Gruppe zu interpretieren, ersetzen oder entfernen Sie das Leerzeichen im Anspruch. Formatieren Sie beispielsweise eine Gruppe mit dem Namen `My Group``MyGroup`.
**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 OIDC-Anbieter müssen Sie beim Hinzufügen der Identitätsquelle einen Tokentyp auswählen. Sie können zwischen ID und Zugriffstoken wählen, und Ihre Wahl schließt die Verarbeitung des nicht ausgewählten Tokentyps in Ihrem Richtlinienspeicher aus. Insbesondere, wenn Sie von der automatischen Zuordnung von ID-Token-Ansprüchen zu Attributen in der Verified Permissions-Konsole profitieren möchten, sollten Sie sich frühzeitig für den Tokentyp entscheiden, 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 OIDC-Anbieter
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.
Für OIDC-ID-Tokens gibt es einen `aud` Anspruch, der den Client enthält IDs, z. B. `1example23456789`
OIDC-Zugriffstoken haben einen `aud` Anspruch, der die Zielgruppen-URL für das Token enthält, wie z. B., und einen `client_id` Anspruch`https://myapplication.example.com`, der den Client IDs enthält, wie z. B. `1example23456789`
Geben Sie beim Einrichten Ihres Richtlinienspeichers einen oder mehrere Werte für die **Zielgruppenvalidierung** ein, die Ihr Richtlinienspeicher verwendet, um die Zielgruppe eines Tokens zu validieren.
+ **ID-Tokens** — Verified Permissions validiert die Kunden-ID, indem überprüft wird, ob mindestens ein Mitglied des Kunden IDs im `aud` Antrag einem Wert für die Zielgruppenvalidierung entspricht.
+ **Zugriffstoken** — Verifizierte Berechtigungen validieren die Zielgruppe, indem überprüft wird, ob die URL im `aud` Anspruch mit einem Zielgruppenvalidierungswert übereinstimmt. Wenn kein `aud` Anspruch besteht, kann die Zielgruppe anhand der `client_id` Ansprüche `cid` oder bestätigt werden. Erkundigen Sie sich bei Ihrem Identitätsanbieter nach der korrekten Angabe und dem richtigen Format für die Zielgruppe.
## 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-Webtoken (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