SAML 2.0 联合身份验证

聚焦模式

SAML 2.0 联合身份验证 - AWS Identity and Access Management

使用基于 SAML 的联合身份验证来对 AWS 进行 API 访问配置基于 SAML 2.0 的联合身份验证的概述用于允许对 AWS 资源进行 SAML 联合访问的角色的概述唯一标识基于 SAML 的联合中的用户

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

注意

IAM SAML 身份联合验证支持来自基于 SAML 的联合身份提供者（IdP）的加密 SAML 响应。IAM Identity Center 和 Amazon Cognito 不支持来自 IAM SAML 身份提供商的加密 SAML 断言。

您可以将对加密 SAML 断言的支持间接添加到具有 Amazon Cognito 用户池的 Amazon Cognito 身份池联合身份验证。用户池具有独立于 IAM SAML 联合身份验证的 SAML 联合身份验证，并且支持 SAML 签名和加密。尽管此功能没有直接扩展到身份池，但用户池可以是身份池的 IDP。要对身份池使用 SAML 加密，请将具有加密的 SAML 提供商添加到一个用户池，其是身份池的 IdP。

SAML 提供商必须能够使用用户池提供的密钥对 SAML 断言进行加密。用户池不接受使用 IAM 提供的证书进行加密的断言。

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

允许组织中的用户或应用程序调用 AWS API 操作的联合访问权限。下面的部分将讨论此用例。您可以使用组织内生成的 SAML 断言 (身份验证响应的一部分) 获得临时安全凭证。此方案类似于 IAM 支持的其他联合方案，如请求临时安全凭证和 OIDC 联合身份验证中介绍的方案。但是，企业中基于 SAML 2.0 的 IdP 可以在运行时处理很多细节功能，以用于执行身份验证和授权检查。
从组织向 AWS Management Console进行基于 Web 的单一登录 (SSO)。用户可以登录您企业中由与 SAML 2.0 兼容的 IdP 托管的门户，选择转向 AWS，并将其重新导向到控制台，而无需提供其他登录信息。您可以使用第三方 SAML IdP 建立对控制台的 SSO 访问，或者可以创建自定义 IdP 来支持外部用户的控制台访问。有关构建自定义 IdP 的更多信息，请参阅使自定义身份凭证代理程序能够访问 AWS 控制台。

主题

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

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

您组织中的用户使用客户端应用程序来请求您组织的 IdP 进行身份验证。
IdP 根据组织的身份存储对用户进行身份验证。
IdP 构建一个具有用户相关信息的 SAML 断言，并将此断言发送到客户端应用程序。当您为 IAM SAML IdP 启用 SAML 加密时，此断言将由外部 IdP 加密。
客户端应用程序调用 AWS STS AssumeRoleWithSAML API，并传递 SAML 提供商的 ARN、要代入的角色的 ARN 以及来自 IdP 的 SAML 断言。如果启用了加密，则通过客户端应用程序传递的断言在传输过程中保持加密状态。
（可选）AWS STS 使用您从外部 IdP 上传的私有密钥来解密加密的 SAML 断言。
API 对客户端应用程序的响应包括临时安全凭证。
客户端应用程序使用临时安全凭证来调用 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联合身份验证配置为支持多个 SAML 登录端点。有关详细信息，请参阅 AWS 安全博客文章如何使用区域性 SAML 端点进行失效转移。

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

将 AWS 注册为您组织的 IdP 的服务提供商（SP）。通过 https://region-code.signin.aws.amazon.com/static/saml-metadata.xml 使用 SAML 元数据文档

有关可能的 region-code 值的列表，请参阅 AWS 登录端点中的 Region（区域）列。

您可以选择通过 https://signin.aws.amazon.com/static/saml-metadata.xml 使用 SAML 元数据文档。
通过使用您企业的 IdP，生成一个同等 SAML 元数据 XML 文件，该文件可将您的 IdP 描述为 AWS 中的 IAM 身份提供者。它必须包括发布者名称、创建日期、过期日期以及 AWS 可用来验证来自您组织的身份验证响应（断言）的密钥。

如果允许从外部 IdP 发送加密的 SAML 断言，则必须使用组织的 IdP 生成私有密钥文件，并以 .pem 文件格式将此文件上传到 IAM SAML 配置。AWS STS 需要此私有密钥文件来解密与上传到 IdP 的公有密钥对应的 SAML 响应。

注意
如 SAML V2.0 元数据互操作性配置文件 1.0 版所定义，IAM 既不会评估 SAML 元数据文档的 X.509 证书，也不会在该证书过期时采取任何行动。如果您担心 X.509 证书过期，建议您监控证书到期日期，并根据贵组织的治理和安全策略来轮换证书。
在 IAM 控制台中，创建一个 SAML 身份提供商。在此过程中，您将上传 SAML 元数据文档和私有解密密钥，这些文档和私有解密密钥是由贵组织中的 IdP 在步骤 2 中生成的。有关更多信息，请参阅在 IAM 中创建 SAML 身份提供者。
在 IAM 中创建一个或多个 IAM 角色。在角色的信任策略中，您可将 SAML 提供商设置为可在您的组织与 AWS 之间建立信任关系的主体。该角色的权限策略确定了允许您组织的用户在 AWS 中执行的操作。有关更多信息，请参阅针对第三方身份提供商创建角色（联合身份验证）。

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

如果您的 IdP 支持对 AWS 控制台的 SSO，则可配置控制台会话的最大持续时间。有关更多信息，请参阅使 SAML 2.0 联合身份用户能够访问 AWS Management Console。
在您正在创建的应用程序中，您可以调用 AWS Security Token Service AssumeRoleWithSAML API，将其传递给您在步骤 3 中创建的 SAML 提供商的 ARN、您在步骤 4 中创建的要代入的角色的 ARN 以及从您的 IdP 处获取的有关当前用户的 SAML 断言。AWS 确保代入角色的请求来自 SAML 提供商所引用的 IdP。

有关更多信息，请参阅https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html API 参考中的 AWS Security Token ServiceAssumeRoleWithSAML。
如果请求成功，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": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://us-west-2.signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

注意

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

策略中的 saml:aud 上下文键指定登录控制台时浏览器显示的 URL。此登录端点 URL 必须与您的身份提供者的收件人属性相匹配。您可以添加特定区域内的登录 URL。AWS 建议使用区域端点而不是全局端点，以提高联合身份验证的韧性。如果您只配置了一个端点，则如果该端点变得不可用（此情况发生可能性极小），您就无法通过联合身份验证登录 AWS。有关可能的 region-code 值的列表，请参阅 AWS 登录端点中的 Region（区域）列。

以下示例显示了带有可选 region-code 的登录 URL 格式。

https://region-code.signin.aws.amazon.com/saml

如果需要 SAML 加密，则登录 URL 必须包含 AWS 分配给您的 SAML 提供商的唯一标识符，您可以在身份提供者详细信息页面上找到该标识符。在以下示例中，登录 URL 包含要求在登录路径后附加 /acs/ 的 IdP 唯一标识符。

https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID

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

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

唯一标识基于 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 控制台或 AWS CLI 创建存储桶 (amzn-s3-demo-bucket) 和文件夹 (app1)，因为这些都是静态值。但是，用户特定文件夹（user1、user2、user3 等）必须在运行时使用代码创建，因为在用户首次通过联合流程登录之前，用来标识用户的值是未知的。

要编写在资源名称中引用特定于用户的详细信息的策略，必须在可以用于策略条件的 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 的 AWS STS 联合身份验证的可用键键。

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

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

有关可用于基于 SAML 的联合的策略键的更多信息，请参阅基于 SAML 的 AWS STS 联合身份验证的可用键。
saml:sub（字符串）。这是该陈述的主题，其中包含唯一标识组织中某个用户的值 (例如 _cbb88bf52c2510eabe00c1642d4643f41430fe25e3)。
saml:sub_type（字符串）。此键可以是 persistent、transient 或在您的 SAML 断言中使用的 Format 和 Subject 元素的完整 NameID URI。persistent 的值表示在所有会话中用户的 saml:sub 值是相同的。如果值为 transient，则用户在每个会话中拥有不同的 saml:sub 值。有关 NameID 元素的 Format 属性的信息，请参阅为身份验证响应配置 SAML 断言。。

以下示例说明了一个权限策略，该策略使用上述密钥为 Amazon S3 中的用户特定文件夹授予权限。该策略假设 Amazon S3 对象使用同时包含 saml:namequalifier 和 saml: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:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

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

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

获取 OIDC 身份提供者的指纹

创建 SAML 身份提供者

本页内容

选择您的 Cookie 首选项

自定义 Cookie 首选项

关键

性能

功能

广告

无法保存 Cookie 首选项

SAML 2.0 联合身份验证

注意

主题

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

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

注意

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

注意

注意

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

注意

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

本页内容

Related resources

此页内容对您是否有帮助？

Related resources

下一主题：

上一主题：

需要帮助吗？

获得基于 SAML 断言的临时安全证书