Cognito 的多租户：一个大用户池还是每个租户一个池？
Multi-Tenancy with Cognito: one big user pool or one pool per tenant?
我知道 Cognito 的各种多租户方法，并且我在精神上致力于“每个租户一个用户池”方法。因此，例如，我们的 AWS 帐户将为租户 A 提供 tenant_a_user_pool，为租户 B 提供 tenant_b_user_pool，等等。但是，现在我已经准备好实施这种方法，我开始有第二个想法，我想知道我是否可以用一个用户池做一些更简单的事情，同时仍然实现我的目标，即：security 和 flexibility
关于安全性，我假设通过用户池分隔用户本质上更安全，只是因为分隔用户的纯粹性质。所以，我的第一个问题是：
- 单独的用户池是否更安全？
- 或者，使用一个用户池和 tenant/user 关系信息存储在数据库中是否同样安全？
至于灵活性，拥有“每个租户一个用户池”将允许为租户 A 配置 SAML 身份验证，而租户 B 可能会选择另一种身份验证方法，比如使用 un/pw 针对他们的用户池进行身份验证。或者，租户 C 可以打开 MFA，而租户 D 可能会关闭它。虽然我不怀疑这种方法是否灵活，但我开始怀疑它是不是太复杂了，我是否可以使用一个用户池来实现同样的目的？
如果我为所有用户使用一个用户池，我正在考虑这样一种方法：
在上面的模型中，我添加了一个关联 table、tenant_users，因为在使用一组登录凭据时可能需要让用户成为多个租户的一部分 (类似于 Slack，我会说）。但是，如果我采用这种方法，我会开始怀疑灵活性。例如，我还能让租户 A 使用 SAML 而租户 B 使用其他身份验证方法吗？ 如果您注意到租户 table，我添加了一个 auth_methods 存储租户首选身份验证方法的列。我希望我可以在 Cognito 触发器调用的 lambda 中为各种身份验证方法添加身份验证逻辑。但是，我正在进入一个陌生的领域，所以我不知道什么是可能的。
回顾一下，我的问题是……
- 所有租户一个用户池是否与每个租户一个用户池一样安全？
- 如果我向租户 table 添加一个 auth_methods 列来指定每个租户的身份验证首选项，我能否通过一个用户池保持灵活性（例如，允许租户选择不同的身份验证方法）？
如有任何其他对此总体方法的评论，我们将不胜感激。
我认为在不知道您正在保护哪些资源以及如何保护它们的情况下很难回答这个问题，例如
- 你是白盒吗？
- 是否所有登录都是平等的，都访问相同的应用程序和资源？
- “租户”中的所有数据在该租户的用户之间是否相等？
- 如何在 Cognito 或其他地方完成授权？
如果所有登录都差不多，那么我会说单租户可能有意义。
一些注意事项：
- 您想为一部分用户提供设备跟踪选项吗？
- MFA 呢？
- 支付 SMS MFA 费用如何？
- 自定义身份验证怎么样，例如无密码？
- 高级安全性如何（每位用户额外 5c）？
如果其中任何一个的答案是肯定的，那么我认为您可以考虑多个用户池，每个帐户的默认上限为 1000 个用户池，但您可以要求亚马逊增加此上限。
我个人使用“大用户池”方法进行身份验证，但我们在 cognito 之外跟踪授权。最令人头疼的是当租户需要高级安全性（能够查看失败的登录、帐户风险等）或 SMS MFA 时，因为它们必须在整个用户池中启用，从而导致成本急剧增加。
您可能会考虑的另一件事是托管 UI 不允许您预先设置用户名，因此如果您使用的表单采用 email/username 然后重定向到他们所在的用户池的适当托管 UI（在多租户情况下）然后他们将需要再次重新输入他们的电子邮件。
如果您决定不使用托管的 UI 并使用您自己的（或 aws amplify），那么您将失去所有 oauth2/oidc 的东西，例如代码流，因此没有 SSO，它使移动应用程序成为可能更难。
另请注意，自定义身份验证不能与 MFA 混合使用，如果您使用自定义身份验证，您也不能使用托管 UI。
我知道 Cognito 的各种多租户方法，并且我在精神上致力于“每个租户一个用户池”方法。因此，例如，我们的 AWS 帐户将为租户 A 提供 tenant_a_user_pool，为租户 B 提供 tenant_b_user_pool，等等。但是，现在我已经准备好实施这种方法，我开始有第二个想法，我想知道我是否可以用一个用户池做一些更简单的事情，同时仍然实现我的目标，即：security 和 flexibility
关于安全性，我假设通过用户池分隔用户本质上更安全，只是因为分隔用户的纯粹性质。所以，我的第一个问题是：
- 单独的用户池是否更安全？
- 或者，使用一个用户池和 tenant/user 关系信息存储在数据库中是否同样安全？
至于灵活性，拥有“每个租户一个用户池”将允许为租户 A 配置 SAML 身份验证，而租户 B 可能会选择另一种身份验证方法，比如使用 un/pw 针对他们的用户池进行身份验证。或者，租户 C 可以打开 MFA，而租户 D 可能会关闭它。虽然我不怀疑这种方法是否灵活，但我开始怀疑它是不是太复杂了，我是否可以使用一个用户池来实现同样的目的？
如果我为所有用户使用一个用户池，我正在考虑这样一种方法：
在上面的模型中，我添加了一个关联 table、tenant_users，因为在使用一组登录凭据时可能需要让用户成为多个租户的一部分 (类似于 Slack，我会说）。但是，如果我采用这种方法，我会开始怀疑灵活性。例如，我还能让租户 A 使用 SAML 而租户 B 使用其他身份验证方法吗？ 如果您注意到租户 table，我添加了一个 auth_methods 存储租户首选身份验证方法的列。我希望我可以在 Cognito 触发器调用的 lambda 中为各种身份验证方法添加身份验证逻辑。但是，我正在进入一个陌生的领域，所以我不知道什么是可能的。
回顾一下，我的问题是……
- 所有租户一个用户池是否与每个租户一个用户池一样安全？
- 如果我向租户 table 添加一个 auth_methods 列来指定每个租户的身份验证首选项，我能否通过一个用户池保持灵活性（例如，允许租户选择不同的身份验证方法）？
如有任何其他对此总体方法的评论，我们将不胜感激。
我认为在不知道您正在保护哪些资源以及如何保护它们的情况下很难回答这个问题，例如
- 你是白盒吗？
- 是否所有登录都是平等的，都访问相同的应用程序和资源？
- “租户”中的所有数据在该租户的用户之间是否相等？
- 如何在 Cognito 或其他地方完成授权？
如果所有登录都差不多，那么我会说单租户可能有意义。
一些注意事项：
- 您想为一部分用户提供设备跟踪选项吗？
- MFA 呢？
- 支付 SMS MFA 费用如何？
- 自定义身份验证怎么样，例如无密码？
- 高级安全性如何（每位用户额外 5c）？
如果其中任何一个的答案是肯定的，那么我认为您可以考虑多个用户池，每个帐户的默认上限为 1000 个用户池，但您可以要求亚马逊增加此上限。
我个人使用“大用户池”方法进行身份验证，但我们在 cognito 之外跟踪授权。最令人头疼的是当租户需要高级安全性（能够查看失败的登录、帐户风险等）或 SMS MFA 时，因为它们必须在整个用户池中启用，从而导致成本急剧增加。
您可能会考虑的另一件事是托管 UI 不允许您预先设置用户名，因此如果您使用的表单采用 email/username 然后重定向到他们所在的用户池的适当托管 UI（在多租户情况下）然后他们将需要再次重新输入他们的电子邮件。
如果您决定不使用托管的 UI 并使用您自己的（或 aws amplify），那么您将失去所有 oauth2/oidc 的东西，例如代码流，因此没有 SSO，它使移动应用程序成为可能更难。
另请注意，自定义身份验证不能与 MFA 混合使用，如果您使用自定义身份验证，您也不能使用托管 UI。