Arbeiten mit Identitätsquellen in Schemas und Richtlinien - Amazon Verified Permissions
Wissenswertes über Schema-MappingZuordnen von ID-TokenZugriffstoken zuordnenAlternative Schreibweise für durch Doppelpunkte getrennte Amazon Cognito-Ansprüche

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 Identitätsquellen in Schemas und Richtlinien

Möglicherweise möchten Sie einem Richtlinienspeicher eine Identitätsquelle hinzufügen und Anbieteransprüche Ihrem Policy-Store-Schema zuordnen. Sie können diesen Vorgang automatisieren oder Ihr Schema manuell aktualisieren. 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 erstelle ich manuell ein Schema für eine Identitätsquelle

API-verknüpfte Richtlinienspeicher und Richtlinienspeicher mit einer Identitätsquelle mithilfe von Guided Setup erfordern keine manuelle Zuordnung von Identitätstokenattributen (ID) zum Schema. Sie können verifizierte Berechtigungen mit den Attributen in Ihrem Benutzerpool oder mit OIDC-Token angeben 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 einen Richtlinienspeicher aus einem Beispiel erstellt.

  • Sie möchten die 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 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. 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. Ihr Schema muss den Entitäten entsprechen, die Anbieter-Tokens in IsAuthorizedWithTokenBatchIsAuthorizedWithToken-API-Anfragen erstellen. 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.

Wissenswertes über Schema-Mapping

Die Attributzuweisung unterscheidet sich zwischen Tokentypen

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 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 einer Identitätsquelle 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. Weitere Informationen finden Sie unter Zugriffstoken zuordnen.

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"

  2. Durch Leerzeichen getrennte Liste:. "groups": "MyGroup1 MyGroup2 MyGroup3" Jede Zeichenfolge ist eine Gruppe.

  3. 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 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 API-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 Ihre 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:groups 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"
      ]
   }
}

Eine Beispielrichtlinie für Attribute, die anhand dieses Schemas validiert werden, sieht wie folgt aus:

permit (
    principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup",
    action,
    resource
) when {
    principal["cognito:username"] == "alice" &&
    principal["custom:employmentStoreCode"] == "petstore-dallas" &&
    principal has email && principal.email == "alice@example.com" &&
    context["ip-address"] like "192.0.2.*"
};

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 Cognito-ID-Token

Amazon Cognito ID-Token funktionieren mit den meisten OIDC-Rely-Party-Bibliotheken. Sie erweitern die Funktionen von OIDC um zusätzliche Ansprüche. Ihre Anwendung kann den Benutzer mit API-Authentifizierungsoperationen für Amazon Cognito Cognito-Benutzerpools oder mit der gehosteten Benutzerpool-Benutzeroberfläche authentifizieren. Weitere Informationen finden Sie unter Using the API and Endpoints 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 (UUID) des Benutzers

Ansprüche mit einem Präfix custom:

Ein Präfix für benutzerdefinierte Benutzerpool-Attribute wiecustom:employmentStoreCode.

Standardansprüche

Standardansprüche von OIDC wie email und. phone_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, beschreibt dieser Anspruch die Rollen, 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 unterBearbeiten von Schemas im JSON-Modus. 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
         }
      }
   }
}

Nachdem Sie Ihr Schema aktualisiert haben, um die Amazon Cognito-Attribute widerzuspiegeln, können Sie Richtlinien erstellen, die auf die Attribute verweisen.

permit (
    principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup",
    action,
    resource
) when {
    principal["cognito:username"] == "alice" &&
    principal["custom:employmentStoreCode"] == "petstore-dallas" &&
    principal.tenant == "x11app-tenant-1" &&
    principal has email && principal.email == "alice@example.com"
};

OIDC-ID-Token

Die Arbeit mit ID-Token von einem OIDC-Anbieter entspricht weitgehend der Arbeit mit Amazon Cognito Cognito-ID-Token. Der Unterschied liegt in den Behauptungen. Ihr IdP kann Standard-OIDC-Attribute 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.

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

Die folgende Richtlinie gilt für Mitglieder einer Gruppe in Ihrem OIDC-Anbieter.

permit (
    principal in MyCorp::UserGroup::"MyOIDCProvider|MyUserGroup",
    action,
    resource
) when {
    principal.email_verified == true && principal.email == "alice@example.com" &&
    principal.phone_number_verified == true && principal.phone_number like "+1206*"
};

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.

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 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, die die Zugriffsberechtigungen des Inhabers des Tokens darstellen.

cognito:groups

Die Gruppenmitgliedschaften eines Benutzers. In einem Autorisierungsmodell, das auf der rollenbasierten Zugriffskontrolle (RBAC) basiert, beschreibt dieser Anspruch die Rollen, 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 unterBearbeiten von Schemas im JSON-Modus.

{
   "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"
         }
      }
   }
}

Nachdem Sie Ihr Schema aktualisiert haben, um die Amazon Cognito-Attribute widerzuspiegeln, können Sie Richtlinien erstellen, die auf die Attribute verweisen.

permit(principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource)
when { 
    context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" &&
    context.token.scope.contains("MyAPI/mydata.write")
};

Zuordnung von OIDC-Zugriffstoken

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 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 unterBearbeiten von Schemas im JSON-Modus.

{
   "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"
         }
      }
   }
}

Nachdem Sie Ihr Schema aktualisiert haben, um die IdP-Attribute widerzuspiegeln, können Sie Richtlinien erstellen, die auf die Attribute verweisen.

permit(
    principal, 
    action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"],
    resource
)
when { 
    context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" &&
    context.token.scope.contains("MyAPI-read")
};

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

Mit einem Schema in diesem Format können Sie eine Richtlinie mit Punktnotation wie im folgenden Beispiel erstellen:

permit(principal, action, resource)
when {
    principal.cognito.username == "alice" &&
    principal.custom.employmentStoreCode == "petstore-dallas" &&
    principal.tenant == "x11app-tenant-1" &&
    principal has email && principal.email == "alice@example.com"
};