AWS Identity and Access Management
用户指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。请点击 Amazon AWS 入门,可查看中国地区的具体差异

关于基于 SAML 2.0 的联合身份验证

AWS 使用 SAML 2.0 (安全断言标记语言 2.0) 支持联合身份验证,SAML 2.0 是许多身份验证提供商 (IdP) 使用的一种开放标准。此功能可实现联合单一登录 (SSO),因此用户可以登录 AWS 管理控制台或调用 AWS API,而不必为组织中的每个人都创建一个 IAM 用户。由于可以使用 IdP 的服务而不必编写自定义身份代理代码,因此您可以通过使用 SAML 来简化为 AWS 配置联合身份验证的过程。

IAM 联合支持这些使用案例:

使用基于 SAML 的联合身份验证来对 AWS 进行 API 访问

假设在您的组织中,您想要为用户提供一种将数据从他们的计算机中复制到备份文件夹的方法。您可以构建一个可在用户的计算机上运行的应用程序。在后端,该应用程序可在 S3 存储桶中读写对象。用户没有直接访问 AWS 的权限。而应使用以下过程:

 获得基于 SAML 断言的临时安全凭证
  1. 您组织中的用户使用客户端应用程序来请求您组织的 IdP 进行身份验证。

  2. IdP 根据组织的身份存储对用户进行身份验证。

  3. IdP 构建一个具有用户相关信息的 SAML 断言,并将此断言发送到客户端应用程序。

  4. 客户端应用程序调用 AWS STS AssumeRoleWithSAML API,并传递 SAML 提供商的 ARN、要代入的角色的 ARN 以及来自 IdP 的 SAML 断言。

  5. API 对客户端应用程序的响应包括临时安全凭证。

  6. 客户端应用程序使用临时安全凭证来调用 Amazon S3 API。

配置基于 SAML 2.0 的联合身份验证的概述

在使用前面方案和图表中所述的基于 SAML 2.0 的联合身份验证之前,您必须先配置组织的 IdP 和您的 AWS 账户,使之相互信任。以下步骤介绍了用于配置此信任的一般过程。组织内部必须有支持 SAML 2.0 的 IdP,例如 Microsoft Active Directory 联合身份验证服务 (AD FS,Windows Server 的一部分)、Shibboleth 或其他兼容的 SAML 2.0 提供商。

配置组织的 IdP 和 AWS 使之相互信任

  1. 首先,将 AWS 注册到 IdP。在您组织的 IdP 中,您可以使用来自以下 URL 的 SAML 元数据文档将 AWS 注册为服务提供商 (SP):

    https://signin.amazonaws.cn/static/saml-metadata.xml

  2. 通过使用您组织的 IdP,生成一个同等元数据 XML 文件,该文件可将您的 IdP 描述为 AWS 的身份提供商。它必须包括发布者名称、创建日期、过期日期以及 AWS 可用来验证来自您组织的身份验证响应(断言)的密钥。

  3. 在 IAM 控制台中,创建一个 SAML 身份提供商实体。在此过程中,您将上传您组织的 IdP 在步骤 2 中生成的 SAML 元数据文档。有关更多信息,请参阅 创建 SAML 身份提供商

  4. 在 IAM 中,您可以创建一个或多个 IAM 角色。在角色的信任策略中,您可将 SAML 提供商设置为可在贵组织与 AWS 之间建立信任关系的委托人。该角色的权限策略确定了允许您组织的用户在 AWS 中执行的操作。有关更多信息,请参阅 针对第三方身份提供商创建角色 (联合)

  5. 在您组织的 IdP 中,定义可将您组织中的用户或组映射到 IAM 角色的断言。请注意,贵组织中不同的用户和组可能映射到不同的 IAM 角色。执行映射的确切步骤取决于您使用的 IdP。在用户的 Amazon S3 文件夹的早期方案中,可能出现所有用户映射到提供 Amazon S3 权限的同一角色的情况。有关更多信息,请参阅 为身份验证响应配置 SAML 断言

    如果您的 IdP 支持对 AWS 控制台的 SSO,则可配置控制台会话的最大持续时间。有关更多信息,请参阅 使 SAML 2.0 联合身份用户能够访问 AWS 管理控制台

    注意

    SAML 2.0 联合的 AWS 实施不支持身份提供商与 AWS 之间的加密 SAML 断言。但是,客户系统与 AWS 之间的通信在加密的 (TLS) 通道上进行传输。

  6. 在您正在创建的应用程序中,您将调用 AWS Security Token Service AssumeRoleWithSAML API,向其传递您在步骤 3 中创建的 SAML 提供商的 ARN、在步骤 4 中创建的要担任角色的 ARN,以及从 IdP 处获取的有关当前用户的 SAML 断言。AWS 确保担任角色的请求来自 SAML 提供商所引用的 IdP。

    有关更多信息,请参阅 AWS Security Token Service API 参考中的 AssumeRoleWithSAML

  7. 如果请求成功,API 会返回一组临时安全证书,您的应用程序即可用其向 AWS 发出已签名的请求。您的应用程序具有有关当前用户的信息并可访问 Amazon S3 中用户特定的文件夹,如上一方案中所述。

用于允许对 AWS 资源进行 SAML 联合访问的角色的概述

您在 IAM 中创建的角色将确定允许您组织中的联合身份用户在 AWS 中执行的操作。当您为角色创建信任策略时,您可以将先前创建的 SAML 提供商指定为 Principal。此外,您还可以使用 Condition 设置信任策略的范围,以便仅允许与特定 SAML 属性匹配的用户访问角色。例如,您可以指定仅允许 SAML 从属关系为 staff (在 https://openidp.feide.no 中断言) 的用户访问角色,如以下示例策略所示:

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"AWS": "arn:aws-cn:iam::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/ExampleOrgSSOProvider"}, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "saml:aud": "https://signin.amazonaws.cn/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]} } }] }

有关您可以签入策略的 SAML 密钥的更多信息,请参阅基于 SAML 的联合的可用键

对于该角色中的权限策略,您可以像任何角色一样指定权限。例如,如果允许您组织的用户管理 Amazon Elastic Compute Cloud 实例,您必须在权限策略中明确允许 Amazon EC2 操作,如 AmazonEC2FullAccess 托管策略中的操作。

唯一标识基于 SAML 的联合中的用户

在 IAM 中创建访问策略时,可根据用户的身份指定权限,这一点通常很有用。举例来说,对于已使用 SAML 联合的用户,应用程序可能希望使用如下的结构保留 Amazon S3 中的信息:

myBucket/app1/user1 myBucket/app1/user2 myBucket/app1/user3

您可以通过 Amazon S3 控制台或 AWS CLI 创建存储桶 (myBucket) 和文件夹 (app1),因为这些都是静态值。然而,用户特定的文件夹 (user1user2user3 等)必须在运行时使用代码创建,因为在用户首次通过联合流程登录之前,用来标识用户的值是未知的。

要编写在资源名称中引用特定于用户的详细信息的策略,必须在可以用于策略条件的 SAML 键中提供用户身份。以下键可供基于 SAML 2.0 的联合在 IAM 策略中使用。您可以使用以下键返回的值为资源 (如 Amazon S3 文件夹) 创建唯一的用户标识符。

  • saml:namequalifier. 哈希值,基于 Issuer 响应值 (saml:iss)、包含 AWS 账户 ID 的字符串和 IAM 中 SAML 提供商的友好名称 (ARN 的最后一部分) 的串联。账户 ID 与 SAML 提供商的友好名称的串联可作为键 saml:doc 供 IAM 策略使用。账户 ID 与提供商名称必须使用“/”分隔,例如在“123456789012/provider_name”中。有关更多信息,请参阅 基于 SAML 的联合的可用键 上的 saml:doc 键。

    NameQualifierSubject 的组合可用于唯一识别联合身份用户。以下伪代码显示如何计算此值。在此伪代码中,+ 表示串联,SHA1 代表使用 SHA-1 生成消息摘要的功能,Base64 代表生成哈希输出的 Base-64 编码版本的功能。

    Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

    有关可用于基于 SAML 的联合的策略键的更多信息,请参阅基于 SAML 的联合的可用键

  • saml:sub (字符串)。这是该陈述的主题,其中包含唯一标识组织中某个用户的值 (例如 _cbb88bf52c2510eabe00c1642d4643f41430fe25e3)。

  • saml:sub_type (字符串)。此键可以是 persistenttransient 或在您的 SAML 断言中使用的 SubjectNameID 元素的完整 Format URI。persistent 的值表示在所有会话中用户的 saml:sub 值是相同的。如果值为 transient,则用户在每个会话中拥有不同的 saml:sub 值。有关 NameID 元素的 Format 属性的信息,请参阅为身份验证响应配置 SAML 断言

以下示例说明了一个权限策略,该策略使用上述密钥为 Amazon S3 中的用户特定文件夹授予权限。该策略假设 Amazon S3 对象使用同时包含 saml:namequalifiersaml:sub 的前缀进行标识。请注意,Condition 元素包括一个测试,用于确保 saml:sub_type 设置为 persistent。如果已设置为 transient,每个会话用户的 saml:sub 值可以不同,且不应使用值的组合来标识用户特定的文件夹。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws-cn:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}", "arn:aws-cn:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }

有关将断言从 IdP 映射到策略的更多信息,请参阅为身份验证响应配置 SAML 断言