使用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，以此类推.但是，既然我已经准备好实现此方法，我开始有了新的想法，我想知道我是否可以在实现我的目标的同时，用一个用户池做一些更简单的事情，这些目标是:安全和灵活性

I’m aware of the various multi-tenant approaches with Cognito and I’ve mentally committed to the "one user pool per tenant" method. So, for example, our AWS account would have tenant_a_user_pool for tenant A and tenant_b_user_pool for tenant B, etc. BUT, now that I’m ready to implement this approach, I’m starting to have second thoughts and I’m wondering if I could do something more simple with one user pool while still achieving my goals, which are: security and flexibility

关于安全性，我已经假设仅通过将用户分开的纯粹本质，将用户按用户池分开本质上就更安全.所以，我的第一个问题是:

Regarding security, I’ve made the assumption that having users separated by user pool is inherently more secure just by the sheer nature of having users separated. So, my first questions are:

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

关于灵活性，拥有每个租户一个用户池"将允许为租户A配置SAML身份验证，而租户B可以选择另一种身份验证方法，例如针对其用户池使用un/pw进行身份验证.或者，租户C可以打开MFA，而租户D可以将其关闭.尽管我不确定这种方法是否灵活，但我开始怀疑它是否太复杂了，是否可以使用一个用户池来实现相同的目的?

As for flexibility, having "one user pool per tenant" will allow for configuring SAML authentication for tenant A while tenant B might choose another authentication method, say authenticating with un/pw against their user pool. Or, tenant C can turn on MFA and tenant D might leave it off. While I don’t doubt that this approach can be flexible, I am starting to wonder if it is too complex and if I can achieve the same using one user pool?

如果我为所有用户使用一个用户池，那么我正在考虑采用以下方法:

If I go with one user pool for all users, I was thinking of an approach such as this:

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

In the model above, I’ve added an association table, tenant_users, as there might be a requirement to have users be part of multiple tenants while using one set of login credentials (similar to Slack, I’d say). But, if I go this approach, I start to wonder about flexibility. For example, can I still have tenant A use SAML and tenant B use some other authentication method? If you notice in the tenants table, I’ve added an auth_methods column which would store the tenants preferred authentication method. I’m hoping I can add the authentication logic for the various authentication methods in a lambda invoked by a Cognito trigger. But, I’m heading into unfamiliar territory so I don’t know what’s possible or not.

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

To recap, my questions are…

1. 所有租户的一个用户池是否和每个租户的一个用户池一样安全?
2. 如果我在租户表中添加一个auth_methods列来指定每个租户的身份验证首选项，是否可以保持灵活性(例如，允许租户选择不同的身份验证方法)?

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

Any other comments on this overall approach would be greatly appreciated.

推荐答案

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

I think it's a hard question to answer without knowing what resources you are protecting and also how you are protecting them, e.g.

• 您正在白牌吗?
• 所有登录名是否相等，都访问相同的应用程序和资源?
• 是否将所有数据存储在租户"中?在那个租户的用户之间平等?
• 在认知模式或其他方式下，授权是如何完成的?

如果所有登录数几乎相等，那么我想说一个租户可能有意义.

If all logins are pretty much equal then I would say single tenant may make sense.

有些事情要记住:

• 您想为一部分用户提供设备跟踪选项吗?
• MFA是什么?
• 如何为SMS MFA付费?
• 有关自定义身份验证的信息，例如没有密码?
• 高级安全性(每位用户额外5c)是什么?

如果对这些问题的答案是肯定的，那么我认为您可能会考虑使用多个用户池，每个帐户的默认上限为1000个用户池，但是您可以要求亚马逊提高该数量.

If the answer to any of these is yes then I think you might consider multiple user pools, there is a default cap of 1000 user pools per account but you can request amazon increase this.

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

Personally I have used the "big user pool" approach for authentication however we tracked authorization outside of cognito. The biggest headache is when a tenant wants advanced security (ability to see failed logins, account risks etc) or SMS MFA as they have to be enable across the user pool causing dramatically increased costs.

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

Another thing you may consider is that the hosted UI does not allow you to pre-set the user name, so if you are using a form that takes the email/username and then redirect to the appropriate hosted UI (in a multi-tenant situation) for the user pool they are in then they will need to re-enter their email again.

如果您决定不使用托管的UI并使用自己的用户界面(或AWS放大)，则会丢失所有oauth2/oidc内容(例如代码流)，因此将失去SSO，这会使移动应用程序变得更难.

If you decide to not use the hosted UI and user your own (or aws amplify) then you lose all the oauth2/oidc stuff such as code flow so no SSO and it makes mobile apps harder.

还请注意，自定义身份验证不能与MFA混合使用，如果您使用自定义身份验证，则也不能使用托管UI.

Also note custom auth cannot be mixed with MFA and if you use custom auth you also cannot use the hosted UI.

这篇关于使用Cognito进行多租户:一个大用户池还是每个租户一个池?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！