使用 Amazon Verified Permissions 進行授權

Amazon Verified Permissions 是一項授權服務，適用於您建置的應用程式。當您新增 Amazon Cognito 使用者集區做為身分來源時，您的應用程式就可以將使用者集區存取權或身分 (ID) 權杖傳遞給 Verified Permissions 以決定允許或拒絕。Verified Permissions 會根據您使用 Cedar 政策語言撰寫的政策來考量您使用者的屬性和請求內容。請求內容可包括所請求文件、影像或其他資源的識別符，以及您的使用者想要對資源執行的動作。

您的應用程序可以將用戶的身份或訪問令牌提供給已驗證權限IsAuthorizedWithToken或 BatchIsAuthorizedWithTokenAPI 請求。這些 API 作業會接受您的使用者，Principal並針對他們想要存取Action的Resource項目做出授權決策。其他自訂Context可以有助於詳細的存取決策。

當您的應用程式在 IsAuthorizedWithToken API 請求中顯示權杖時，Verified Permissions 就會執行以下驗證。

您的使用者集區是針對所請求的政策存放區設定的 Verified Permissions 身分來源。
client_id 或 aud 宣告分別位在您的存取或身分權杖中，兩者之一會符合您提供給 Verified Permissions 的使用者集區應用程式用戶端 ID。若要驗證此宣告，您必須在您的 Verified Permissions 身分來源中設定用戶端 ID 驗證。
您的權杖未過期。
令牌中token_use聲明的值與您傳遞給的參數匹配IsAuthorizedWithToken。access如果您將其傳遞給accessToken參數，並且將其傳遞給參數，id則該token_useidentityToken聲明必須是。
權杖中的簽名來自您的使用者集區已發布的 JSON Web 金鑰 (JWK)。您可以在 https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json 檢視您的 JWK。

撤銷的權杖和刪除的使用者

Verified Permissions 只會驗證從您的身分來源得知的資訊，以及您使用者的權杖到期時間資訊。Verified Permissions 不會檢查權杖是否撤銷或使用者是否存在。即使您撤銷了使用者的權杖，或是從使用者集區刪除了使用者的設定檔，在權杖過期之前，Verified Permissions 仍會將該權杖視為有效。

政策評估

將您的使用者集區設定為政策存放區的身分來源。設定讓您的應用程式在請求中提交使用者的權杖給 Verified Permissions。Verified Permissions 會針對每個請求，將權杖中的宣告與政策進行比較。Verified Permissions 政策就像 AWS 中的 IAM 政策。它會宣告主體、資源和動作。Allow如果「已驗證權限」符合允許的動作且不符合明確Deny動作，則會以「驗證權限」回應您的要求；否則，它會以回應Deny。如需詳細資訊，請參閱《Amazon Verified Permissions User Guide》中的 Amazon Verified Permissions policies。

自訂權杖

若要變更、新增和移除您要呈現給已驗證權限的使用者宣告，請使用產生權杖前 Lambda 觸發程序. 使用權杖產生前觸發程序，您就可以新增和修改權杖中的宣告。例如，您可以查詢資料庫中的其他使用者屬性，並將這些屬性編碼到您的 ID 權杖中。

注意

由於 Verified Permissions 處理宣告的方式，請勿在您的權杖產生前函數中新增名為 cognito、dev 或 custom 的宣告。若您不是採用冒號分隔格式 (如 cognito:username) 顯示這些保留的宣告字首，而是採用完整宣告名稱，那麼您的授權請求便會失敗。

其他資源

具有已驗證權限的 API 授權

您的 ID 或存取權杖可以授權對具有已驗證許可的後端 Amazon API Gateway REST API 的請求。您可以建立原則存放區，其中包含使用者集區和 API 的立即連結。使用「使用 Cognito 和 API Gateway 設定」啟動選項，「已驗證的權限」會將使用者集區身分識別來源新增至政策存放區，並將 Lambda 授權者新增至 API。當您的應用程式將使用者集區承載權杖傳遞至 API 時，Lambda 授權者會叫用已驗證的權限。授權者將 Token 作為主體傳遞，並將請求路徑和方法作為動作傳遞。

下圖說明具有已驗證權限的 API Gateway API 的授權流程。如需詳細細資料，請參閱 Amazon 驗證許可使用者指南中的 API 連結政策存放區。

說明使用 Amazon 驗證許可的 API 授權流程的圖表。應用程式向 Amazon API Gateway API 發出請求。API 會叫用 Lambda 授權者。授權者向「已驗證的權限」發出 API 請求。驗證權限檢查令牌有效性並返回授權決策。

已驗證的權限結構圍繞用戶集區組的 API 授權。由於 ID 和存取權杖都包含cognito:groups宣告，因此您的原則存放區可以在各種應用程式內容中管理 API 的角色型存取控制 (RBAC)。

選擇策略存放區設定

在原則存放區上設定身分識別來源時，您必須選擇是要處理存取權或 ID Token。這項決定對您的政策引擎的運作方式非常重要。ID 令牌包含用戶屬性。訪問令牌包含用戶訪問控制信息：O Auth 範圍。雖然這兩種權杖類型都有群組成員資格資訊，但我們通常建議使用具有已驗證權限原則存放區的 RBAC 存取權杖。訪問令牌添加到具有範圍的組成員資格中，這些範圍可以促進授權決策。訪問令牌中的聲明成為授權請求中的上下文。

當您將使用者集區設定為身分識別來源時，也必須設定使用者和群組實體類型。實體類型是主參與者、動作和資源識別元，您可以在已驗證的權限原則中參照。原則存放區中的實體可以具有成員資格關係，其中一個實體可以是父實體的成員。有了成員資格，您就可以參照主參與者群組、動作群組和資源群組。在使用者集區群組的情況下，您指定的使用者實體類型必須是群組實體類型的成員。當您在 [已驗證的權限] 主控台中設定 API 連結的原則存放區或遵循 [引導式設定] 時，您的原則存放區會自動具有此父成員關係。

ID 令牌可以將 RBAC 與基於屬性的訪問控制（ABAC）結合使用。建立 API 連結的原則存放區之後，您可以使用使用者屬性和群組成員資格來增強您的策略。ID 令牌中的屬性聲明成為授權請求中的主要屬性。您的原則可以根據主參與者屬性做出授權決策。

您也可以設定政策存放區，以接受符合您提供之可接受應用程式用戶端清單的aud或client_id宣告的權杖。

角色型 API 授權的範例政策

下列範例原則是透過針對範PetStore例 REST API 設定已驗證權限原則存放區所建立。


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

在以下情況下，驗證權限會從您的應用程式傳回授權要求的Allow決定：

您的應用程序在Authorization標題中傳遞 ID 或訪問令牌作為承載令牌。
您的應用程序傳遞了一個帶有包含該字符串的cognito:groups聲明的令牌MyGroup。
您的應用程式HTTP GET向 (例如，https://myapi.example.com/pets或) 提出要求https://myapi.example.com/pets/scrappy。

Amazon Cognito 使用者的政策範例

您的使用者集區也可以在 API 要求以外的情況下，產生對已驗證權限的授權要求。您可以將應用程式中的任何存取控制決策提交至原則存放區。例如，您可以在任何請求傳輸網路之前，使用以屬性為基礎的存取控制來補充 Amazon DynamoDB 或 Amazon S3 安全性，從而減少配額使用。

以下範例使用 Cedar 政策語言，允許透過某一個使用者集區應用程式用戶端進行驗證的財務使用者讀取和寫入 example_image.png。John 是您的應用程式中的使用者，他從您的應用程式用戶端收到 ID 權杖，並在 GET 請求中將該權杖傳遞至需要授權的 URL https://example.com/images/example_image.png。John 的 ID 權杖內有您的使用者集區應用程式用戶端 ID 1234567890example 的 aud 宣告。您的權杖產生前 Lambda 函數還針對 John 插入了一個值為 Finance1234 的新宣告 costCenter。


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

以下請求內文會產生 Allow 回應。


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

若您想要在 Verified Permissions 政策中指定主體，請使用下列格式：


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

以下是識別碼為 sub 或使用者 ID us-east-1_Example 之使用者集區中之使用者的範例主體973db890-092c-49e4-a9d0-912a4c0a20c7。


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

當您要在 [已驗證權限] 原則中指定使用者群組時，請使用下列格式：


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

下面是一個例子

屬性型存取控制

針對您的應用程式具有已驗證許可的授權，以及適用於 AWS 登入資料的 Amazon Cognito 身分集區的存取控制功能的屬性都是以屬性為基礎的存取控制 (ABAC)。以下是 Verified Permissions 與 Amazon Cognito ABAC 的比較。在 ABAC 中，系統會檢查實體的屬性，並從您定義的條件做出授權決策。

服務	處理	結果
Amazon Verified Permissions	從使用者集區 JWT 的分析傳回`Allow`或`Deny`決策。	根據 Cedar 原則評估，存取應用程式資源會成功或失敗。
Amazon Cognito 可身份集區 (用於存取控制的屬性)	根據用戶的屬性將會話標籤分配給用戶。IAM 政策條件可以檢查標籤`Allow`或`Deny`使用者的存取權 AWS 服務。	具有 IAM 角色臨時 AWS 登入資料的標記工作階段。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

整合應用程式

程式碼範例