# 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_cn/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)。