authentication - Cognito 的多租户：一个大用户池还是每个租户一个池？

Question

我知道 Cognito 的各种多租户方法，并且我在精神上致力于“每个租户一个用户池”方法。因此，例如，我们的 AWS 账户将有租户 A 的 tenant_a_user_pool 和租户 B 的 tenant_b_user_pool 等。但是，现在我已经准备好实施这种方法，我开始有第二个想法，我想知道我是否可以用一个用户池做一些更简单的事情，同时仍然实现我的目标，即：安全性和灵活性

关于安全性，我假设将用户按用户池分隔在本质上更安全，这仅仅是因为用户分隔的本质。所以，我的第一个问题是：

1. 单独的用户池是否更安全？
2. 或者，使用存储在数据库中的租户/用户关系信息的用户池是否同样安全？

至于灵活性，“每个租户一个用户池”将允许为租户 A 配置 SAML 身份验证，而租户 B 可能会选择另一种身份验证方法，例如使用 un/pw 对其用户池进行身份验证。或者，租户 C 可以打开 MFA，而租户 D 可能会将其关闭。虽然我不怀疑这种方法可以灵活，但我开始怀疑它是否过于复杂，是否可以使用一个用户池实现相同的效果？

如果我为所有用户使用一个用户池，我正在考虑这样一种方法：

在上面的模型中，我添加了一个关联表，tenant_users，因为在使用一组登录凭据时可能需要让用户成为多个租户的一部分（类似于 Slack，我会说）。但是，如果我采用这种方法，我开始怀疑灵活性。例如，我仍然可以让租户 A 使用 SAML 而租户 B 使用其他身份验证方法吗？ 如果您在租户表中注意到，我添加了一个 auth_methods 列，该列将存储租户首选的身份验证方法。我希望我可以在 Cognito 触发器调用的 lambda 中为各种身份验证方法添加身份验证逻辑。但是，我正在进入陌生的领域，所以我不知道什么是可能的。

回顾一下，我的问题是……</p>

1. 所有租户的一个用户池是否与每个租户一个用户池一样安全？
2. 如果我将 auth_methods 列添加到指定每个租户的身份验证首选项的租户表中，我能否使用一个用户池保持灵活性（例如，允许租户选择不同的身份验证方法）？

对这种整体方法的任何其他评论将不胜感激。

标签： authenticationamazon-cognitomulti-tenant

Answer 1

我认为这是一个很难回答的问题，而不知道您正在保护哪些资源以及如何保护它们，例如

• 你是白盒吗？
• 所有登录是否都相同，都访问相同的应用程序和资源？
• “租户”中的所有数据在该租户的用户之间是否相等？
• 授权是如何完成的，在 cognito 中还是在其他地方？

如果所有登录名几乎相同，那么我会说单租户可能有意义。

需要记住的一些事项：

• 您想为一部分用户提供设备跟踪选项吗？
• 外交部呢？
• 为 SMS MFA 付费怎么样？
• 自定义身份验证怎么样，例如无密码？
• 高级安全性如何（每位用户额外 5c）？

如果其中任何一个的答案是肯定的，那么我认为您可能会考虑多个用户池，每个帐户的默认上限为 1000 个用户池，但您可以要求亚马逊增加这个上限。

我个人使用“大用户池”方法进行身份验证，但是我们在 cognito 之外跟踪授权。最令人头疼的是当租户需要高级安全性（能够查看失败的登录、帐户风险等）或 SMS MFA 时，因为它们必须在整个用户池中启用，从而导致成本显着增加。

您可能会考虑的另一件事是托管 UI 不允许您预先设置用户名，因此，如果您使用的表单采用电子邮件/用户名，然后重定向到适当的托管 UI（在多租户情况下） ) 对于他们所在的用户池，那么他们将需要再次重新输入他们的电子邮件。

如果您决定不使用托管 UI 并使用您自己的（或 aws amplify），那么您将丢失所有 oauth2/oidc 内容，例如代码流，因此没有 SSO，这会使移动应用程序变得更加困难。

另请注意，自定义身份验证不能与 MFA 混合使用，如果您使用自定义身份验证，您也无法使用托管 UI。