SAML 2.0 联合身份验证
Amazon 使用 SAML 2.0(安全断言标记语言 2.0)
IAM 联合支持这些使用案例:
-
允许组织中的用户或应用程序调用 Amazon API 操作的联合访问权限。下面的部分将讨论此用例。您可以使用组织内生成的 SAML 断言 (身份验证响应的一部分) 获得临时安全凭证。此方案类似于 IAM 支持的其他联合方案,如 请求临时安全凭证 和 OIDC 联合身份验证 中介绍的方案。但是,企业中基于 SAML 2.0 的 IdP 可以在运行时处理很多细节功能,以用于执行身份验证和授权检查。
-
从组织向 Amazon Web Services Management Console进行基于 Web 的单一登录 (SSO)。用户可以登录您企业中由与 SAML 2.0 兼容的 IdP 托管的门户,选择转向 Amazon,并将其重新导向到控制台,而无需提供其他登录信息。您可以使用第三方 SAML IdP 建立对控制台的 SSO 访问,或者可以创建自定义 IdP 来支持外部用户的控制台访问。有关构建自定义 IdP 的更多信息,请参阅使自定义身份凭证代理程序能够访问 Amazon 控制台。
主题
使用基于 SAML 的联合身份验证来对 Amazon 进行 API 访问
假设您想要为员工提供一种将数据从他们的计算机中复制到备份文件夹的方法。您可以构建一个可在用户的计算机上运行的应用程序。在后端,该应用程序可在 Amazon S3 存储桶中读写对象。用户没有直接访问 Amazon 的权限。而应使用以下过程:
-
您组织中的用户使用客户端应用程序来请求您组织的 IdP 进行身份验证。
-
IdP 根据组织的身份存储对用户进行身份验证。
-
IdP 构建一个具有用户相关信息的 SAML 断言,并将此断言发送到客户端应用程序。
-
客户端应用程序调用 Amazon STS
AssumeRoleWithSAML
API,并传递 SAML 提供商的 ARN、要代入的角色的 ARN 以及来自 IdP 的 SAML 断言。 -
API 对客户端应用程序的响应包括临时安全凭证。
-
客户端应用程序使用临时安全凭证来调用 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 以使之相互信任
-
将 Amazon 注册为您组织的 IdP 的服务提供商(SP)。通过
https://
使用 SAML 元数据文档region-code
.signin.amazonaws.cn/static/saml-metadata.xml有关可能的
region-code
值的列表,请参阅 Amazon 登录端点中的 Region(区域)列。您可以选择通过
https://signin.amazonaws.cn/static/saml-metadata.xml
使用 SAML 元数据文档。 -
通过使用您企业的 IdP,生成一个同等元数据 XML 文件,该文件可将您的 IdP 描述为 Amazon 中的 IAM 身份提供程序。它必须包括发布者名称、创建日期、过期日期以及 Amazon 可用来验证来自您组织的身份验证响应(断言)的密钥。
-
在 IAM 控制台中,创建一个 SAML 身份提供商。在此过程中,您将上传 SAML 元数据文档,这些文档和私有解密密钥是由贵组织中的 IdP 在 步骤 2 中生成的。有关更多信息,请参阅 在 IAM 中创建 SAML 身份提供者。
-
在 IAM 中创建一个或多个 IAM 角色。在角色的信任策略中,您可将 SAML 提供商设置为可在您的组织与 Amazon 之间建立信任关系的主体。该角色的权限策略确定了允许您组织的用户在 Amazon 中执行的操作。有关更多信息,请参阅 针对第三方身份提供商创建角色(联合身份验证)。
注意
角色信任策略中使用的 SAML IdP 必须与角色位于同一账户中。
-
在您企业的 IdP 中,定义可将您企业中的用户或组映射到 IAM 角色的断言。请注意,您的组织中不同的用户和组可能映射到不同的 IAM 角色。执行映射的确切步骤取决于您使用的 IdP。在用户 Amazon S3 文件夹中的较早场景中,则所有用户都可能映射到提供 Amazon S3 权限的同一角色。有关更多信息,请参阅 为身份验证响应配置 SAML 断言。。
如果您的 IdP 支持对 Amazon 控制台的 SSO,则可配置控制台会话的最大持续时间。有关更多信息,请参阅 使 SAML 2.0 联合身份用户能够访问 Amazon Web Services Management Console。
-
在您正在创建的应用程序中,您可以调用 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。
-
如果请求成功,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.xmlsaml: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
),因为这些都是静态值。但是,用户特定文件夹(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 的 Amazon STS 联合身份验证的可用键 键。NameQualifier
与Subject
的组合可用于唯一识别联合身份用户。以下伪代码显示如何计算此值。在此伪代码中,+
表示串联,SHA1
代表使用 SHA-1 生成消息摘要的功能,Base64
代表生成哈希输出的 Base-64 编码版本的功能。Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )
有关可用于基于 SAML 的联合的策略键的更多信息,请参阅基于 SAML 的 Amazon 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-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 断言。。