知识产权用户池和联合身份之间的服务差异

Question

AWS提供cognito,为开发人员提供注册和登录功能,包括与OpenId兼容身份提供商(如facebook,google等)的联合.

cognito开发者控制台中有两种类别.这些是管理用户池和管理联合身份.

我只是有点困惑,因为两者非常相似,即使我们想要提供我们的客户登录他们的Facebook帐户.cognito用户池本身提供联合身份验证和联合身份池,也由身份验证提供程序提供.

问题是,如果我想允许我的客户使用自己的Facebook帐户登录,我应该使用哪些类别？用户池或联合身份？

另外,如果我想在API网关中配置授权器,我必须创建cognito用户池但联合身份池.这是选择认知类别的主要原因吗？

Answer 1

Cognito用户池:

Amazon Cognito用户池使开发人员可以轻松地向Web和移动应用程序添加注册和登录功能.它作为您自己的身份提供者来维护用户目录.它支持用户注册和登录,以及为登录用户配置身份令牌.

Cognito联合身份或身份池:

另一方面,Cognito Identity Pool(或Cognito Federated Identities)是一种授权用户使用各种AWS服务的方法.假设您希望允许用户访问您的S3存储桶,以便他们可以上传文件; 您可以在创建标识池时指定.为了创建这些访问级别,Identity Pool有自己的身份(或用户)概念.这些身份(或用户)的来源可以是Cognito用户池,甚至是Facebook或Google.

用户池和标识池之间的关系:

Cognito Identity Pool只需要将所有身份提供者放在一起(将它们联合起来).通过所有这些,它现在可以为您的用户提供对AWS服务的安全访问,无论他们来自何处.

总而言之,Cognito用户池存储了所有用户,然后插入到Cognito Identity Pool中,这可以让用户访问AWS服务.

资源

Answer 2

您可以将用户池视为包含用户属性(如姓名,电子邮件,电话号码等)的目录.这还提供注册,登录功能.您可以将用户联合到用户池中.目前,您可以使用Facebook,Google和SAML作为用户池的身份提供商.

Cognito联合身份允许您将用户联合到AWS并发布可用于访问策略中允许的资源的AWS凭据.对于Cognito Federated Identities,您还可以配置各种身份提供程序,例如Facebook,Google,以及Cognito用户池可以是身份提供程序.

您使用的内容取决于您的使用案例.如果您的应用不需要AWS资源,则可能只需要用户池.

Answer 3

我认为 AWS 应该将用户池和身份池分开，并更改名称。因为在同一个名称下混合不同的服务会导致混淆，并且名称不会提供有关服务的任何线索。

• User Pool -> AWS Authentication and Token Vending service，类似于Auth0。您可以使用 Auth0 而不是不必要的复杂用户池
• 身份池 -> AWS IAM 授权服务，用于身份验证令牌，例如 Auth0 令牌或 AWS JWT 令牌（来自用户池）

一个类比是：

• Use Pool 是您所在国家/地区的一个机构，用于识别您的身份并签发 VISA（VISA 是身份提供商为您提供的用户令牌）。

• 身份池是您使用 VISA 访问的称为“AWS”的外国的边境控制。他们通过 VISA 验证您的身份并授权您在那里可以做什么。如果边境管制不承认签证，你就什么也做不了。如果他们认识到这一点，那么他们就会为每个 VISA 定义细粒度的规则，允许哪些操作以及在何处执行。

忘记用户池

更好地关注身份池。因为用户池只是另一个身份提供者服务，如 MSAD、Google、Facebook、Auth0 等。身份提供者进行身份验证并提供令牌，例如为 MS AD 用户提供 Kerberos 令牌，或为 AWS Cognito 用户池用户提供 Cognito Userpool JWT 令牌。然后身份池可以利用令牌来授权对 AWS 资源的访问。

除了奇怪的命名之外，AWS 一直将身份提供者/身份验证服务与身份池/授权服务混为一谈，因此造成了大量混淆，引发了问题。

“身份池”这个名字没有任何意义，因为它没有说明服务的作用。一个词必须引导思维，导致理解，而不是混淆。AWS 恰恰相反。

准备

在跳到身份池的作用之前，最好先了解一些事情。

AWS STS 令牌

天真地说，AWS STS Token允许我们以编程方式创建、使用、更新、删除 AWS 资源。

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN

如果您有 AWS 账户用户，您可以为该用户获取 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY，然后使用例如 MFA 获取 STS 令牌。

IAM 角色

实际上，IAM 角色定义了 STS 令牌在哪些 AWS 资源上允许的操作。它可能不允许删除但允许创建。因此，这取决于 STS 令牌允许我们做什么的 IAM 角色。

但是，需要注意的一点是，您获得的 IAM 角色和 STS Token 之间存在关联，并且必须有人为您定义关联。

身份池为您提供什么

它提供了一个STS Token，您可以使用它来操作 AWS 账户中的 AWS 资源。

身份池有用的情况

AWS 对我来说的另一个问题是他们的文档没有声明这是当您需要 Identity Pool 时，而是不断重复单词Federation，它没有指向 Identity Pool 的作用，允许您使用 STS Token 操作 AWS 资源。

如果您处于以下情况：

• 我想操作 AWS 账户中的 AWS 资源，并且
• 我没有 AWS IAM 用户（或者我不想使用它），但是
• 我在 Corporate AD、Google、Facebook、Auth0、...或 Cognito 用户池中拥有一个帐户。

然后您可以使用身份池为您登录的帐户（例如 Google）获取 STS 令牌，并可以操作 AWS 资源。

例如，如果您的公司 AD 中有 1000 多个用户，并希望让他们以某种方式使用 AWS 资源。您会创建 1000 多个 AWS IAM 用户吗？或者找到一种方法将它们映射到一些 IAM 角色，例如“管理员”、“会计”、“财务”、“IT”？

身份池的作用

身份池将身份提供商令牌（例如 Google 令牌）映射到AWS 帐户中的IAM 角色，并提供 STS 令牌。

根据我的理解，AWS 将此“映射”称为Federation。

我建议在讨论身份池时完全忘记用户池。用户池只是您可能根本不需要的另一个身份提供者。

同样，在讨论用户池时，我建议完全忘记身份池。

我确实希望 AWS 将身份提供者服务（用户池）与令牌映射服务（身份池）分开，以免造成混淆。