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 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