authentication - 使用 Cognito 的 Multi-Tenancy : one big user pool or one pool per tenant?

Question

我知道 Cognito 的各种 Multi-Tenancy 方法，并且我在精神上致力于“每个租户一个用户池”方法。因此，例如，我们的 AWS 帐户将为租户 A 提供 tenant_a_user_pool，为租户 B 提供 tenant_b_user_pool 等。但是，既然我已经准备好实现这种方法，我开始重新考虑，我想知道我是否可以用一个用户池做一些更简单的事情，同时仍然实现我的目标，即:安全和灵 active

关于安全性，我假设通过用户池分隔用户本质上更安全，只是因为分隔用户的纯粹性质。所以，我的第一个问题是:

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

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

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

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

回顾一下，我的问题是......

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

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

Answer 1

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

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

如果所有登录都差不多，那么我会说单租户可能有意义。

注意事项:

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

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

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

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

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

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