Zuordnen von ID-Token Zugriffstoken zuordnen Alternative Schreibweise für durch Doppelpunkte getrennte Amazon Cognito-Ansprüche Wissenswertes über Schema-Mapping

Zuordnen von Identitätsanbieter-Tokens zum Schema

Möglicherweise möchten Sie einem Richtlinienspeicher eine Identitätsquelle hinzufügen und Kartenanbieteransprüche auf Ihr Richtlinienspeicherschema übertragen. Sie können diesen Vorgang automatisieren oder Ihr Schema manuell aktualisieren. 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 und OIDC Token-Ansprüche in Ihren Richtlinien für verifizierte Berechtigungen
Wie erstellt man manuell ein Schema für eine Identitätsquelle

API-Für verknüpfte Richtlinienspeicher und Richtlinienspeicher mit einer Identitätsquelle, die über die geführte Installation erstellt wurden, ist keine manuelle Zuordnung von Identitätstokenattributen (ID) zum Schema erforderlich. 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 Amazon Cognito Cognito-Token möglicherweise manuell Ihrem Schema zuordnen:

Sie haben einen leeren Richtlinienspeicher oder Richtlinienspeicher anhand eines Beispiels erstellt.
Sie möchten die Verwendung von Zugriffstoken über die rollenbasierte Zugriffskontrolle () RBAC hinaus erweitern.
Sie erstellen Richtlinienspeicher mit den Verifizierten Berechtigungen REST API AWS SDK, an oder. AWS CDK

Um Amazon Cognito oder 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, in denen Anbieter-Tokens erstellt IsAuthorizedWithTokenoder BatchIsAuthorizedWithTokenAPIangefordert werden. 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 im Amazon Cognito Developer Guide.

Themen

Zuordnen von ID-Token zum Schema
Zugriffstoken zuordnen
Alternative Schreibweise für durch Doppelpunkte getrennte Amazon Cognito-Ansprüche
Wissenswertes über Schema-Mapping

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 attributbasierten Autorisierungsmodell für die Zugriffskontrolle (ABAC) 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 Cognito-ID-Token

Amazon Cognito ID-Token funktionieren mit den meisten OIDCRely-Party-Bibliotheken. Sie erweitern die Funktionen von OIDC um zusätzliche Ansprüche. Ihre Anwendung kann den Benutzer mit den API Authentifizierungsoperationen von Amazon Cognito Cognito-Benutzerpools oder mit der vom Benutzerpool gehosteten Benutzeroberfläche authentifizieren. Weitere Informationen finden Sie unter Verwenden der Endpunkte API und im Amazon Cognito Developer Guide.

Nützliche Angaben in Amazon Cognito Cognito-ID-Tokens

cognito:username und preferred_username: Varianten des Benutzernamens.
sub: Die eindeutige Benutzerkennung des Benutzers (UUID)
Ansprüche mit einem custom: Präfix: Ein Präfix für benutzerdefinierte Benutzerpool-Attribute wiecustom:employmentStoreCode.
Standardansprüche: OIDCStandardansprüche wie email undphone_number. Weitere Informationen finden Sie unter Standardansprüche in OpenID Connect Core 1.0, in denen Errata Set 2 enthalten ist.
cognito:groups: 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 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 Formatprincipal["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-Token aus Amazon Cognito-Benutzerpools finden Sie unter Verwenden des ID-Tokens im Amazon Cognito Developer Guide.

Das folgende Beispiel für ein ID-Token hat jeden der vier Attributtypen. Es umfasst den Amazon Cognito-spezifischen Antragcognito:username, den benutzerdefinierten Antrag, den Standardantrag custom:employmentStoreCode und den email 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 Cognito-Benutzerpool eine Identitätsquelle erstellen, geben Sie den Typ der Prinzipalentität an, mit IsAuthorizedWithToken der Verified Permissions in Autorisierungsanfragen generiert. 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 unterPolicy-Store-Schemas im JSON Modus bearbeiten. Wenn Ihre Identitätsquellenkonfiguration den Prinzipaltyp angibtUser, 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 unterSpiegelt Amazon Cognito Cognito-ID-Token-Attribute wider.

OIDCID-Token

Die Arbeit mit ID-Token eines OIDC Anbieters entspricht weitgehend der Arbeit mit Amazon Cognito Cognito-ID-Token. Der Unterschied liegt in den Behauptungen. Ihr IdP kann OIDCStandardattribute 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 Token-Ansprü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.

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 unterSpiegelt OIDC ID-Token-Attribute wider.

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 API den Zugriff enthalten. Zugriffstoken sind in Autorisierungsmodellen nützlich, die eine rollenbasierte Zugriffskontrolle () verwenden. RBAC Autorisierungsmodelle, die auf anderen Zugriffstoken-Ansprüchen als der Gruppenmitgliedschaft basieren, erfordern zusätzlichen Aufwand bei der Schemakonfiguration.

Zuordnen von Amazon Cognito Cognito-Zugriffstoken

Amazon Cognito Cognito-Zugriffstoken haben Ansprüche, die für die Autorisierung verwendet werden können:

Nützliche Angaben in Amazon Cognito Cognito-Zugriffstoken

client_id: Die ID der Client-Anwendung einer OIDC vertrauenden 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 OAuth2.0-Bereiche, 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 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-Benutzerpools finden Sie unter Verwenden des Zugriffstokens im Amazon Cognito Developer Guide.

Ein Amazon Cognito Cognito-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 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 unterPolicy-Store-Schemas im JSON Modus bearbeiten.


{
   "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 unterSpiegelt die Attribute des Amazon Cognito Cognito-Zugriffstokens wider.

OIDCZugriffstoken zuordnen

Die meisten Zugriffstoken von externen OIDC Anbietern stimmen eng mit den Zugriffstoken von Amazon Cognito überein. Ein OIDC 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 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"
}


{
   "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 unterSpiegelt die Attribute von OIDC Zugriffstoken.

Alternative Schreibweise für durch Doppelpunkte getrennte Amazon Cognito-Ansprüche

Zu dem Zeitpunkt, als Verified Permissions gestartet wurde, beanspruchte das empfohlene Schema für Amazon Cognito Cognito-Token „Gefällt mir“ cognito:groups und diese durch Doppelpunkte getrennten Zeichenketten wurden custom:store konvertiert, um das . Zeichen als Hierarchie-Trennzeichen zu 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. 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.

Sie können weiterhin die Punktnotation in manuell erstellten Schemas und Richtlinien für Amazon Cognito Cognito-Identitätsquellen verwenden. Sie können die Punktnotation mit : oder anderen nicht alphanumerischen Zeichen in Schemas oder Richtlinien für keinen anderen IdP-Typ verwenden. OIDC

In einem Schema für die Punktnotation wird jede Instanz eines : Zeichens als untergeordnetes Element der Wortgruppe cognito oder der custom Anfangsphrase verschachtelt, 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 unterVerwendet Punktnotation, um auf Attribute zu verweisen.

Wissenswertes über Schema-Mapping

Die Attributzuweisung unterscheidet sich je nach Token-Typ

Bei der Autorisierung von Zugriffstoken ordnet Verified Permissions Ansprüche dem Kontext 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 einer 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.

RBACbenö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 rollenbasierten Zugriffskontrollmodell () ausführen. RBAC Durch das Hinzufügen von Tokenansprüchen zum Schema wird der Autorisierungsbereich Ihres Richtlinienspeichers erweitert. Benutzerattribute aus ID-Tokens enthalten Informationen über Benutzer, die zur attributebasierten Zugriffskontrolle () ABAC 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.

Mit den Optionen „Mit API Gateway und einem Identitätsanbieter einrichten“ und „Geführte Einrichtung“ in der Konsole „Verified Permissions“ werden dem Schema ID-Token-Ansprüche zugewiesen. 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 Attribute hinzufügen. commonTypes Weitere Informationen finden Sie unter Zugriffstoken zuordnen.

OIDCDer Gruppenanspruch unterstützt mehrere Formate

Wenn Sie einen OIDC Anbieter hinzufügen, können Sie den Namen des Gruppenanspruchs in Form von ID- oder Zugriffstoken auswählen, den Sie der Gruppenmitgliedschaft eines Benutzers in Ihrem Richtlinienspeicher zuordnen möchten. Bei verifizierten Berechtigungen werden Gruppenansprüche in den folgenden Formaten erkannt:

Zeichenfolge ohne Leerzeichen: "groups": "MyGroup"
Durch Leerzeichen getrennte Liste:. "groups": "MyGroup1 MyGroup2 MyGroup3" Jede Zeichenfolge ist eine Gruppe.
JSON(kommagetrennte) Liste: "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 GroupMyGroup.

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 Cognito-Identitätsanbieter haben Sie die Wahl zwischen dem Tokentyp, wenn Sie einen API -verknüpften Richtlinienspeicher erstellen. Wenn Sie einen mit einem APILink verknüpften Richtlinienspeicher erstellen, müssen Sie wä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 Ihr API Gateway. API 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 wieprincipal.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 unterVerwendet die Klammernotation, um auf Token-Attribute zu verweisen.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Identitätsquellen bearbeiten

Anfragen autorisieren