SAML 2.0 联合身份验证 - Amazon Identity and Access Management
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

SAML 2.0 联合身份验证

Amazon 使用 SAML 2.0(安全断言标记语言 2.0)支持联合身份验证,SAML 2.0 是许多身份验证提供商 (IdP) 使用的一种开放标准。此功能可实现联合单点登录(SSO),因此用户可以登录 Amazon Web Services Management Console 或调用 Amazon API 操作,而不必为企业中的每个人都创建一个 IAM 用户。通过使用 SAML,您可以使用 Amazon 简化配置联合身份验证流程,因为您可以使用 IdP 的服务而不是编写自定义身份代理代码

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

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

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

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

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

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

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

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

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

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

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

注意

为了提高联合身份验证弹性,我们建议您将 IdP 和Amazon联合身份验证配置为支持多个 SAML 登录端点。有关详细信息,请参阅 Amazon 安全博客文章如何使用区域性 SAML 端点进行失效转移

配置组织的 IdP 和 Amazon 以使之相互信任
  1. 将 Amazon 注册为您组织的 IdP 的服务提供商(SP)。通过 https://region-code.signin.amazonaws.cn/static/saml-metadata.xml 使用 SAML 元数据文档

    有关可能的 region-code 值的列表,请参阅 Amazon 登录端点中的 Region(区域)列。

    您可以选择通过 https://signin.amazonaws.cn/static/saml-metadata.xml 使用 SAML 元数据文档。

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

  3. 在 IAM 控制台中,创建一个 SAML 身份提供商。在此过程中,您将上传 SAML 元数据文档,这些文档和私有解密密钥是由贵组织中的 IdP 在 步骤 2 中生成的。有关更多信息,请参阅 在 IAM 中创建 SAML 身份提供者

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

    注意

    角色信任策略中使用的 SAML IdP 必须与角色位于同一账户中。

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

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

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

    有关更多信息,请参阅https://docs.amazonaws.cn/STS/latest/APIReference/API_AssumeRoleWithSAML.html API 参考中的 Amazon Security Token ServiceAssumeRoleWithSAML

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

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

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

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Federated": "arn:aws-cn:iam::account-id: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 IdP 必须与角色位于同一账户中。

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

您可以在 https://region-code.signin.aws.amazon.com/static/saml-metadata.xml 中包含 saml:aud 属性的区域端点。有关可能的 region-code 值的列表,请参阅 Amazon 登录端点中的 Region(区域)列。

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

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

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

amzn-s3-demo-bucket/app1/user1 amzn-s3-demo-bucket/app1/user2 amzn-s3-demo-bucket/app1/user3

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

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

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

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

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

    有关可用于基于 SAML 的联合的策略键的更多信息,请参阅基于 SAML 的 Amazon STS 联合身份验证的可用键

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

  • saml:sub_type(字符串)。此键可以是 persistenttransient 或在您的 SAML 断言中使用的 FormatSubject 元素的完整 NameID 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:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}", "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }

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