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

# AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的許可
<a name="id_credentials_temp_control-access_assumerole"></a>

所擔任角色的許可政策，將會決定由 `AssumeRole`、`AssumeRoleWithSAML` 和 `AssumeRoleWithWebIdentity` 傳回的臨時安全憑證的許可。當您建立或更新角色時定義這些許可。

或者，您可以傳遞內嵌或受管的[工作階段政策](access_policies.md#policies_session)作為 `AssumeRole`、`AssumeRoleWithSAML` 或 `AssumeRoleWithWebIdentity` API 操作的參數。工作階段政策會為該角色的臨時憑證工作階段限制許可。所產生工作階段的許可會是角色的身分類型政策和工作階段政策的交集。您可以在後續 AWS API 呼叫中使用角色的臨時登入資料，來存取擁有該角色之帳戶中的資源。您無法使用工作階段政策來授予超出即將擔任角色之以身分為基礎政策所允許的許可。若要進一步了解 AWS 如何決定角色的有效許可，請參閱[政策評估邏輯](reference_policies_evaluation-logic.md)。

![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)


進行「允許」或「拒絕」授權決策 AWS 時， `AssumeRole` 不會評估連接至發出原始呼叫之登入資料的 政策。使用者暫時放棄其原始許可，以支援由擔任角色指派的許可。在 `AssumeRoleWithSAML`和 `AssumeRoleWithWebIdentity` API 操作中，由於 API 的發起人不是 AWS 身分，因此沒有要評估的政策。

## 範例：使用 AssumeRole 指派許可
<a name="permissions-assume-role-example"></a>

您可以將 `AssumeRole` API 操作與不同類型的政策一起使用。以下是幾個範例。

### 角色許可政策
<a name="permissions-assume-role-example-role-access-policy"></a>

在此範例中，您在呼叫 `AssumeRole` API 操作時未使用選用 `Policy` 參數來指定工作階段。指派給臨時憑證的許可由所擔任角色的許可政策決定。以下範例許可政策授予角色許可，以列出名為 `productionapp` 的 S3 儲存貯體中包含的所有物件。它還允許角色取得、放置和刪除該儲存貯體中的物件。

**Example 角色許可政策範例**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}
```

### 工作階段政策作為參數傳遞
<a name="permissions-assume-role-example-passed-policy"></a>

假設您想要讓使用者擔任與上一個範例相同的角色。但是，此時您希望該角色工作階段擁有的許可，只允許其取得 `productionapp` S3 儲存貯體中的物件，以及在其中放入物件。您不想讓他們刪除物件。實現此目的一種方法是建立新的角色並在該角色的許可政策中指定所需許可。實現此目的之另一種方法是呼叫 `AssumeRole` API，並將工作階段政策包含在可選的 `Policy` 參數做為 API 操作的一部分。所產生工作階段的許可會是角色的以身分為基礎的政策和工作階段政策的交集。工作階段政策不能用來授予超出即將擔任角色之以身分為基礎政策所允許的許可。如需有關角色工作階段許可的詳細資訊，請參閱 [工作階段政策](access_policies.md#policies_session)。

擷取新的工作階段臨時憑證後，您可以將這些資料傳遞給您希望擁有這些許可的使用者。

例如，假設以下政策做為 API 呼叫的參數傳遞。使用這項工作階段的人員所擁有的許可，將僅能執行下列動作：
+ 列出 `productionapp` 儲存貯體中的所有物件。
+ 取得並將物件放入 `productionapp` 儲存貯體中。

在以下工作階段政策中，`s3:DeleteObject` 許可會遭篩除，而且擔任的工作階段不會獲得 `s3:DeleteObject` 許可的授予。此政策設定角色工作階段的最大許可，並供以覆寫該角色的任何現有許可政策。

**Example 工作階段使用`AssumeRole` API 呼叫傳遞政策範例**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}
```

### 以資源為基礎的政策
<a name="permissions-assume-role-example-resource-based-policy"></a>

有些 AWS 資源支援以資源為基礎的政策，這些政策提供另一個機制來定義影響臨時安全登入資料的許可。只有少數資源 (例如 Amazon S3 儲存貯體、Amazon SNS 主題和 Amazon SQS 佇列) 支援資源式政策。以下範例使用名為 `productionapp` 的 S3 儲存貯體擴展前面的範例。以下政策連接至儲存貯體。

當您將下面以資源為基礎的政策連接到 `productionapp` 儲存貯體時，將拒絕*所有*使用者從儲存貯體中刪除物件的許可。(請參閱政策中的 `Principal` 元素。) 這包括所有擔任角色使用者，即使角色許可政策授予 `DeleteObject` 許可。明確 `Deny` 陳述式一律優先於 `Allow` 陳述式。

**Example 儲存貯體政策的範例**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}
```

如需如何合併和評估多個政策類型的詳細資訊 AWS，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md)。