Autorisierung mit Amazon Verified Permissions

Amazon Verified Permissions ist ein Autorisierungsservice für die von Ihnen erstellten Anwendungen. Wenn Sie einen Amazon-Cognito-Benutzerpool als Identitätsquelle hinzufügen, kann Ihre App Benutzerpoolzugriffs- oder Identitäts-Token (ID) an Verified Permissions weitergeben, um eine Entscheidung über Zulassen oder Ablehnen zu treffen. Verified Permissions berücksichtigt die Eigenschaften und den Anforderungskontext Ihres Benutzers auf der Grundlage von Richtlinien, die Sie in Cedar Policy Language verfasst haben. Der Anforderungskontext kann eine Kennung für das angeforderte Dokument, Bild oder eine andere Ressource sowie die Aktion enthalten, die Ihr Benutzer für die Ressource ausführen möchte.

Ihre App kann die Identität Ihres Benutzers oder Zugriffstoken für verifizierte Berechtigungen in IsAuthorizedWithTokenoder BatchIsAuthorizedWithTokenAPI-Anfragen bereitstellen. Diese API-Operationen akzeptieren Ihre Benutzer als Benutzer Principal und treffen Autorisierungsentscheidungen für die Action Person, auf Resource die sie zugreifen möchten. Zusätzliche benutzerdefinierte Context Einstellungen können zu einer detaillierten Zugriffsentscheidung beitragen.

Wenn Ihre App in einer IsAuthorizedWithToken-API-Anfrage ein Token präsentiert, führt Verified Permissions die folgenden Validierungen durch.

1. Ihr Benutzerpool ist eine konfigurierte Identitätsquelle für Verified Permissions für den angeforderten Richtlinienspeicher.

2. Der client_id- oder aud-Anspruch in Ihrem Zugriffs- bzw. Identitäts-Token entspricht einer Client-ID für eine Benutzerpool-App, die Sie für Verified Permissions angegeben haben. Um diesen Anspruch zu überprüfen, müssen Sie die Client-ID-Validierung in Ihrer Verified-Permissions-Identitätsquelle konfigurieren.

3. Ihr Token ist nicht abgelaufen.

4. Der Wert des token_use Anspruchs in Ihrem Token entspricht den Parametern, an die Sie übergeben habenIsAuthorizedWithToken. Der token_use Anspruch muss lauten, access wenn Sie ihn an den accessToken Parameter übergeben haben und id ob Sie ihn an den identityToken Parameter übergeben haben.

5. Die Signatur in Ihrem Token stammt aus den veröffentlichten JSON-Webschlüsseln (JWKs) Ihres Benutzerpools. Sie können Ihre JWKs unter https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json einsehen.

Widerrufene Token und gelöschte Benutzer

Verified Permissions validiert nur die Informationen, die es aus Ihrer Identitätsquelle und aus der Ablaufzeit des Tokens Ihres Benutzers kennt. Verified Permissions überprüft nicht, ob ein Token gesperrt wurde oder ob ein Benutzer existiert. Wenn Sie das Token Ihres Benutzers gesperrt oder sein Benutzerprofil aus Ihrem Benutzerpool gelöscht haben, betrachtet Verified Permissions das Token weiterhin als gültig, bis es abläuft.

Richtlinienevaluierung

Konfigurieren Sie Ihren Benutzerpool als Identitätsquelle für Ihren Richtlinienspeicher. Konfigurieren Sie Ihre App so, dass sie die Token Ihrer Benutzer in Anfragen an Verified Permissions übermittelt. Für jede Anfrage vergleicht Verified Permissions die Ansprüche im Token mit einer Richtlinie. Eine Richtlinie für Verified Permissions entspricht einer IAM-Richtlinie in  AWS. Sie deklariert einen Prinzipal, eine Ressource und eine Aktion. Verified Permissions beantwortet Ihre Anfrage mit, Allow ob sie mit einer zulässigen Aktion übereinstimmt und nicht mit einer expliziten Deny Aktion; andernfalls wird mit geantwortetDeny. Weitere Informationen finden Sie in den Richtlinien von Amazon Verified Permissions im Benutzerhandbuch zu Amazon Verified Permissions.

Anpassen von Token

Um die Benutzeransprüche, die Sie Verified Permissions vorlegen möchten, zu ändern, hinzuzufügen oder zu entfernen, passen Sie den Inhalt Ihrer Zugriffs- und Identitätstoken mit einem anLambda-Auslöser für die Vorab-Generierung von Token. Mit einem Auslöser für die Vorab-Generierung von Token können Sie Ansprüche in Ihren Token hinzufügen und ändern. Sie können beispielsweise eine Datenbank nach zusätzlichen Benutzerattributen abfragen und diese in Ihr ID-Token kodieren.

Anmerkung

Aufgrund der Art und Weise, wie Verified Permissions Ansprüche verarbeitet, sollten Sie Ihrer Funktion für die Vorab-Generierung von Token keine Ansprüche mit cognito-, dev- oder custom-Namen hinzufügen. Wenn Sie diese reservierten Anspruchspräfixe nicht im durch Doppelpunkte getrennten Format wie cognito:username, sondern als vollständige Anspruchsnamen angeben, schlagen Ihre Autorisierungsanfragen fehl.

Weitere Informationen darüber, wie Verified Permissions Ansprüche in Amazon-Cognito-Token zu Autorisierungsrichtlinien zuordnet, finden Sie unter Zuordnen von Amazon-Cognito-Token zum Verified-Permissions-Schema.

API-Autorisierung mit verifizierten Berechtigungen

Ihre ID oder Zugriffstoken können Anfragen an Back-End-REST-APIs von Amazon API Gateway mit verifizierten Berechtigungen autorisieren. Sie können einen Richtlinienspeicher mit direkten Links zu Ihrem Benutzerpool und Ihrer API erstellen. Mit der Startoption Mit Cognito und API Gateway einrichten fügt Verified Permissions dem Richtlinienspeicher eine Identitätsquelle für den Benutzerpool und der API einen Lambda-Authorizer hinzu. Wenn Ihre Anwendung ein Benutzerpool-Bearer-Token an die API weitergibt, ruft der Lambda-Authorizer Verified Permissions auf. Der Autorisierer übergibt das Token als Principal und den Anforderungspfad und die Methode als Aktion.

Das folgende Diagramm zeigt den Autorisierungsablauf für eine API-Gateway-API mit verifizierten Berechtigungen. Eine detaillierte Aufschlüsselung finden Sie unter API-verknüpfte Policy-Stores im Amazon Verified Permissions User Guide.

Verified Permissions strukturiert die API-Autorisierung anhand von Benutzerpoolgruppen. Da sowohl ID- als auch Zugriffstoken einen cognito:groups Anspruch enthalten, kann Ihr Richtlinienspeicher die rollenbasierte Zugriffskontrolle (RBAC) für Ihre APIs in einer Vielzahl von Anwendungskontexten verwalten.

Einstellungen für den Richtlinienspeicher auswählen

Wenn Sie eine Identitätsquelle in einem Richtlinienspeicher konfigurieren, müssen Sie auswählen, ob Sie Zugriffs- oder ID-Token verarbeiten möchten. Diese Entscheidung ist wichtig für die Funktionsweise Ihrer Policy-Engine. ID-Token enthalten Benutzerattribute. Zugriffstoken enthalten Informationen zur Benutzerzugriffskontrolle: OAuth-Bereiche. Obwohl beide Tokentypen Informationen zur Gruppenmitgliedschaft enthalten, empfehlen wir generell das Zugriffstoken für RBAC mit einem Richtlinienspeicher für verifizierte Berechtigungen. Das Zugriffstoken erweitert die Gruppenmitgliedschaft um Bereiche, die zur Autorisierungsentscheidung beitragen können. Die Ansprüche in einem Zugriffstoken werden in der Autorisierungsanfrage zum Kontext.

Sie müssen auch die Entitätstypen Benutzer und Gruppe konfigurieren, wenn Sie einen Benutzerpool als Identitätsquelle konfigurieren. Bei Entitätstypen handelt es sich um Prinzipal-, Aktions- und Ressourcen-IDs, auf die Sie in den Richtlinien für verifizierte Berechtigungen verweisen können. Entitäten in Richtlinienspeichern können eine Mitgliedschaftsbeziehung haben, bei der eine Entität Mitglied einer übergeordneten Entität sein kann. Mit der Mitgliedschaft können Sie auf Hauptgruppen, Aktionsgruppen und Ressourcengruppen verweisen. Bei Benutzerpoolgruppen muss der von Ihnen angegebene Benutzer-Entitätstyp Mitglied des Gruppen-Entitätstyps sein. Wenn Sie einen API-verknüpften Richtlinienspeicher einrichten oder der geführten Installation in der Konsole „Verifizierte Berechtigungen“ folgen, hat Ihr Richtlinienspeicher automatisch diese Beziehung zwischen übergeordnetem Mitglied.

Das ID-Token kann RBAC mit attributebasierter Zugriffskontrolle (ABAC) kombinieren. Nachdem Sie einen API-verknüpften Richtlinienspeicher erstellt haben, können Sie Ihre Richtlinien mit Benutzerattributen und Gruppenmitgliedschaften erweitern. Die Attributansprüche in einem ID-Token werden zu Hauptattributen in der Autorisierungsanfrage. Ihre Richtlinien können Autorisierungsentscheidungen auf der Grundlage von Hauptattributen treffen.

Sie können einen Richtlinienspeicher auch so konfigurieren, dass er Token akzeptiert, deren client_id Anspruch aud oder mit einer Liste akzeptabler App-Clients übereinstimmt, die Sie bereitstellen.

Beispielrichtlinie für die rollenbasierte API-Autorisierung

Die folgende Beispielrichtlinie wurde durch die Einrichtung eines Richtlinienspeichers für verifizierte Berechtigungen für eine PetStoreBeispiel-REST-API erstellt.

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

Verified Permissions gibt in Allow folgenden Fällen eine Entscheidung über die Autorisierungsanfrage Ihrer Anwendung zurück:

1. Ihre Anwendung hat eine ID oder ein Zugriffstoken in einem Authorization Header als Trägertoken übergeben.

2. Ihre Anwendung hat ein Token mit einem cognito:groups Anspruch übergeben, der die Zeichenfolge MyGroup enthält.

3. In Ihrer Anwendung wurde beispielsweise eine HTTP GET Anfrage an https://myapi.example.com/pets oder gestellthttps://myapi.example.com/pets/scrappy.

Beispielrichtlinie für einen Amazon-Cognito-Benutzer

Ihr Benutzerpool kann auch Autorisierungsanfragen für verifizierte Berechtigungen unter anderen Bedingungen als API-Anfragen generieren. Sie können alle Entscheidungen zur Zugriffskontrolle in Ihrer Anwendung an Ihren Richtlinienspeicher senden. Sie können beispielsweise die Sicherheit von Amazon DynamoDB oder Amazon S3 durch eine attributebasierte Zugriffskontrolle ergänzen, bevor Anfragen das Netzwerk übertragen, wodurch die Kontingentnutzung reduziert wird.

Im folgenden Beispiel wird die Cedar Policy Language verwendet, um Finance-Benutzern, die sich bei einem Benutzerpool-App-Client authentifizieren, das Lesen und Schreiben von example_image.png zu ermöglichen. John, ein Benutzer in Ihrer App, erhält ein ID-Token von Ihrem App-Client und leitet es in einer GET-Anfrage an eine URL weiter, für die eine Autorisierung erforderlich ist, https://example.com/images/example_image.png. Johns ID-Token hat einen aud-Anspruch auf die Client-ID Ihrer Benutzerpool-App 1234567890example. Ihre Lambda-Funktion für die Vorab-Generierung von Token hat auch einen neuen Anspruch costCenter mit einem Wert für John von Finance1234 eingefügt.

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

Der folgende Anfragetext führt zu einer Allow-Antwort.

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

Wenn Sie in einer Richtlinie für Verified Permissions einen Prinzipal angeben möchten, verwenden Sie das folgende Format:

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

Im Folgenden finden Sie ein Beispiel für einen Prinzipal für einen Benutzer in einem Benutzerpool mit einer ID us-east-1_Example mit Sub oder Benutzer-ID. 973db890-092c-49e4-a9d0-912a4c0a20c7

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

Wenn Sie eine Benutzergruppe in einer Richtlinie für verifizierte Berechtigungen angeben möchten, verwenden Sie das folgende Format:

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

Das Folgende ist ein Beispiel

Attributbasierte Zugriffskontrolle

Die Autorisierung mit verifizierten Berechtigungen für Ihre Apps und die Funktion „Attribute für die Zugriffskontrolle“ der Amazon Cognito Cognito-Identitätspools für AWS Anmeldeinformationen sind beide Formen der attributebasierten Zugriffskontrolle (ABAC). Im Folgenden werden die Funktionen von Verified Permissions und Amazon Cognito ABAC miteinander verglichen. In ABAC untersucht ein System die Attribute einer Entität und trifft anhand von Bedingungen, die Sie definieren, eine Autorisierungsentscheidung.

Service	Prozess	Ergebnis
Amazon Verified Permissions	Gibt eine Allow Deny Oder-Entscheidung aus der Analyse eines Benutzerpools zurück (JWT).	Basierend auf der Bewertung der Cedar-Richtlinien ist der Zugriff auf Anwendungsressourcen erfolgreich oder schlägt fehl.
Amazon Cognito Cognito-Identitätspools (Attribute für die Zugriffskontrolle)	Weist Ihrem Benutzer Sitzungs-Tags auf der Grundlage seiner Attribute zu. In den IAM-Richtlinienbedingungen können Tags Allow oder der Deny Benutzerzugriff auf überprüft werden. AWS-Services	Eine mit Tags versehene Sitzung mit temporären AWS Anmeldeinformationen für eine IAM-Rolle.