本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記
<a name="tutorial_abac-saml"></a>

屬性為基礎的存取控制 (ABAC) 是一種授權策略，可根據屬性來定義許可。在 中 AWS，這些屬性稱為標籤。您可以將標籤連接至 IAM 資源，包括 IAM 實體 （使用者或角色） 和 AWS 資源。當實體用於向 提出請求時 AWS，它們會成為委託人，而這些委託人包含標籤。

您也可以在擔任角色或與使用者聯合身分時傳遞[工作階段標籤](id_session-tags.md)。然後您可以定義使用標籤條件索引鍵的政策，以根據主體的標籤來授與許可。當您使用標籤來控制對 AWS 資源的存取 ，您就是允許團隊和資源能夠用更少的 AWS 政策變更來增長。ABAC 政策比傳統 AWS 政策更靈活，需要您列出每個個別資源。如需 ABAC 及其優於傳統政策的詳細資訊，請參閱 [使用 ABAC 授權根據屬性定義許可](introduction_attribute-based-access-control.md)。

如果您的公司使用 SAML 類型的身分提供者 (IdP) 來管理企業使用者身分，您可以將 SAML 屬性用於 AWS中精細的存取控制。屬性可包含成本中心識別符、使用者電子郵件地址、部門分類和專案指派。當您將這些屬性做為工作階段標籤傳遞時，您接著便可以根據這些工作階段標籤來控制對 AWS 的存取。

如要將 SAML 屬性傳遞到您的工作階段主體來完成 [ABAC 教學](tutorial_attribute-based-access-control.md)，請使用本主題中包含的變更，完成 [IAM 教學課程：定義根據標籤存取 AWS 資源的許可](tutorial_attribute-based-access-control.md) 中的任務。

## 先決條件
<a name="tutorial_abac-saml-prerequisites"></a>

如要執行步驟以使用 ABAC 的 SAML 工作階段標籤，您必須已具備以下項目：
+ 對 SAML 類型 IdP 的存取，可讓您使用特定屬性建立測試使用者。
+ 以具有管理許可的使用者身分登入的能力。
+ 體驗在 AWS 管理主控台中建立並編輯 IAM 使用者、角色和政策。不過，如果您需要記住 IAM 管理程序的協助，ABAC 教學課程提供的連結可讓您檢視逐步說明。
+ 在 IAM 中體驗設定 SAML 類型的 IdP。如要檢視更多詳細資訊及更詳細 IAM 文件的連結，請參閱 [使用 AssumeRoleWithSAML 傳遞工作階段標籤](id_session-tags.md#id_session-tags_adding-assume-role-saml)。

## 步驟 1：建立測試使用者
<a name="tutorial_abac-saml-step1"></a>

請跳過 [步驟 1：建立測試使用者](tutorial_attribute-based-access-control.md#tutorial_abac_step1) 中的說明。由於您的身分是定義在您的供應商中，您不需要為您的員工新增 IAM 使用者。

## 步驟 2：建立 ABAC 政策
<a name="tutorial_abac-saml-step2"></a>

遵循 [步驟 2：建立 ABAC 政策](tutorial_attribute-based-access-control.md#tutorial_abac_step2) 中的說明，在 IAM 中建立指定受管政策。

## 步驟 3：建立和設定 SAML 角色
<a name="tutorial_abac-saml-step3"></a>

當您使用 SAML 的 ABAC 教學課程時，您必須執行其他步驟來建立角色、設定 SAML IdP，以及啟用 AWS 管理主控台 存取。如需詳細資訊，請參閱[步驟 3：建立角色](tutorial_attribute-based-access-control.md#tutorial_abac_step3)。

### 步驟 3A：建立 SAML 角色
<a name="tutorial_abac-saml-step3a"></a>

建立單一角色，該角色信任您的 SAML 身分提供者，以及您在步驟 1 中建立的 `test-session-tags` 使用者。ABAC 教學會使用具備不同角色標籤的不同角色。因為您是從您的 SAML IdP 傳遞工作階段標籤，您只需要一個角色。若要了解如何建立 SAML 類型的角色，請參閱 [為 SAML 2.0 聯合身分建立角色 (主控台)](id_roles_create_for-idp_saml.md)。

將角色命名為 `access-session-tags`。將 `access-same-project-team` 許可政策連接到角色。編輯角色信任政策，以使用以下政策。如需如何編輯角色信任關係的詳細說明，請參閱 [更新角色信任政策](id_roles_update-role-trust-policy.md)。

以下角色信任政策會允許您的 SAML 身分提供者和 `test-session-tags` 使用者擔任角色。當 SAML 身分提供者和該使用者擔任角色時，必須傳遞三個指定工作階段標籤。`sts:TagSession` 動作是允許傳遞工作階段標籤的必要項目。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowSamlIdentityAssumeRole",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/cost-center": "*",
                    "aws:RequestTag/access-project": "*",
                    "aws:RequestTag/access-team": [
                        "eng",
                        "qas"
                    ]
                },
                "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
            }
        }
    ]
}
```

------

`AllowSamlIdentityAssumeRole` 陳述式允許工程和品質保證團隊的成員在 AWS 從 Example Corporation IdP 聯合到 時擔任此角色。`ExampleCorpProvider` SAML 供應商是在 IAM 中定義。管理員已設定 SAML 聲明，傳遞三個必要的工作階段標籤。聲明可以傳遞其他標籤，但必須要有這三個標籤。身分的屬性可針對 `cost-center` 和 `access-project` 標籤具備任何值。但是，`access-team` 屬性值必須與 `eng` 或 `qas` 相符，才能指出身分是位於 Engineering 或 Quality Assurance 團隊。

### 步驟 3B：設定 SAML IdP
<a name="tutorial_abac-saml-step3b"></a>

設定您的 SAML IdP，將 `cost-center`、`access-project` 和 `access-team` 屬性做為工作階段標籤傳遞。如需更多詳細資訊，請參閱 [使用 AssumeRoleWithSAML 傳遞工作階段標籤](id_session-tags.md#id_session-tags_adding-assume-role-saml)。

若要將這些屬性做為工作階段標籤傳遞，請在您的 SAML 聲明中包含下列元素。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:cost-center">
  <AttributeValue>987654</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-project">
  <AttributeValue>peg</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-team">
  <AttributeValue>eng</AttributeValue>
</Attribute>
```

### 步驟 3C：啟用主控台存取
<a name="tutorial_abac-saml-step3b"></a>

為您的聯合 SAML 使用者啟用主控台存取。如需更多詳細資訊，請參閱 [啟用 SAML 2.0 聯合主體來存取 AWS 管理主控台](id_roles_providers_enable-console-saml.md)。

## 步驟 4：測試建立秘密
<a name="tutorial_abac-saml-step4"></a>

 AWS 管理主控台 使用 `access-session-tags`角色聯合到 。如需詳細資訊，請參閱[啟用 SAML 2.0 聯合主體來存取 AWS 管理主控台](id_roles_providers_enable-console-saml.md)。然後遵循 [步驟 4：測試建立秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step4) 中的說明來建立秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。如需更多詳細資訊，請參閱 [步驟 4：測試建立秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step4)。

## 步驟 5：測試檢視秘密
<a name="tutorial_abac-saml-step5"></a>

遵循 [步驟 5：測試檢視秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step5) 中的說明來檢視您在上一個步驟中建立的秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。

## 步驟 6：測試可擴展性
<a name="tutorial_abac-saml-step6"></a>

遵循 [步驟 6：測試可擴展性](tutorial_attribute-based-access-control.md#tutorial_abac_step6) 中的說明來測試可擴展性。請使用下列屬性在您的 SAML 類型 IdP 中新增新的身分，來執行此作業：
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`

## 步驟 7：測試更新和刪除秘密
<a name="tutorial_abac-saml-step7"></a>

遵循 [步驟 7：測試更新和刪除秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step7) 中的說明來更新和刪除秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。

**重要**  
刪除您建立的所有秘密來避免產生費用。如需關於 Secrets Manager 定價的詳細資訊，請參閱 [AWS Secrets Manager 定價](https://aws.amazon.com/secrets-manager/pricing/)。

## 摘要
<a name="tutorial-abac-saml-summary"></a>

您現在已成功完成使用 SAML 工作階段標籤和資源標籤進行許可管理必要的所有步驟。

**注意**  
您已新增僅在特定條件下允許執行動作的政策。如果您將不同的政策套用至具有更廣泛許可的使用者或角色，則動作可能不會受限為需要標記。例如，如果您使用 `AdministratorAccess` AWS 受管政策為使用者提供完整的管理許可，則這些政策不會限制該存取。更多涉及多個政策時如何決定許可的詳細資訊，請參閱 [AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。