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 BatchIsAuthorizedWithTokenAPIAnfragen bereitstellen. Bei diesen API Vorgängen werden Ihre Benutzer als Benutzer akzeptiert Principal und Autorisierungsentscheidungen für die Action Person getroffenResource, auf 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 vorlegt, 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 haben. IsAuthorizedWithToken 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 einsehenhttps://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json.

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 verifizierte Berechtigungen ist wie eine 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 Ressourcen

• Zuordnen von Amazon Cognito Cognito-Token zum Schema „Verified Permissions“

• Autorisieren Sie API Gateway APIs mit Amazon Verified Permissions und Amazon Cognito

APIAutorisierung mit verifizierten Berechtigungen

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

Das folgende Diagramm veranschaulicht den Autorisierungsablauf für ein API Gateway API mit verifizierten Berechtigungen. Eine detaillierte Aufschlüsselung finden Sie unter API-linked 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 Sie 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 entscheidend 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 RBAC mit einem Richtlinienspeicher für verifizierte Berechtigungen zu verwenden. 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 mit dem APILink verknüpften Richtlinienspeicher einrichten oder der geführten Installation in der Konsole „Verifizierte Berechtigungen“ folgen, hat Ihr Richtlinienspeicher automatisch diese Beziehung zu einem übergeordneten Mitglied.

Das ID-Token kann RBAC mit der attributbasierten Zugriffskontrolle () kombiniert werden. ABAC Nachdem Sie einen mit einem APILink 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 Autorisierung API

Die folgende Beispielrichtlinie wurde beispielsweise durch die Einrichtung eines Richtlinienspeichers für verifizierte Berechtigungen erstellt. PetStoreRESTAPI

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 Autorisierungsanfragen für verifizierte Berechtigungen auch 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 einen weiter, für den eine Autorisierung erforderlich ist. URL 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 us-east-1_Example mit einer ID mit Sub oder Benutzer-ID973db890-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 attributbasierten Zugriffskontrolle (). ABAC Im Folgenden finden Sie einen Vergleich der Funktionen von Verified Permissions und Amazon CognitoABAC. 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ückJWT.	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. IAMIn den Richtlinienbedingungen können Tags Allow oder der Deny Benutzerzugriff überprüft werden AWS-Services.	Eine mit Tags versehene Sitzung mit temporären AWS Anmeldeinformationen für eine IAM Rolle.