如何限制 AWS Cognito 用户执行某些操作？

Question

我们面临的以下问题需要帮助

任何提示将不胜感激！

细节和环境：

1. 一个多租户应用程序，旨在为每个客户（组织）提供一个专用租户，以实现完全分离。
2. AWS Cognito 用户池作为我用户的数据存储和身份验证提供商。
3. 每个客户（组织）的“AWS Cognito用户池”。
4. 角色管理——基于内置的用户池组。按角色分组，服务器端验证用户的访问令牌是否在其嵌入的组列表中包含组名。

到目前为止一切顺利，一切都按预期工作，使用 AWS Amplify 的 SDK，用于客户端的实施。Amplify 表现良好，让我可以随心所欲。服务器验证组归属等。

问题：

我想限制非管理员用户（不属于“管理员”组）通过 Amplify 执行某些 Cognito 操作。2 例子：

1. 我想通过 Amplify 禁用非管理员用户修改特定属性值的能力。
2. 我想禁用非管理员用户通过 Amplify 为自己修改 MFA 设置的能力。

当我希望管理员能够为其他用户设置 MFA（启用/禁用）时，实际问题就开始了，但在 Cognito（据我所知）中，只有用户可以设置他自己的 MFA 设置。

我看到并已经尝试过的：

1. 设置用户属性的读/写权限。因此，我想要保护的特定属性只能通过具有开发人员凭据的 API 调用进行修改。这样，管理员可以调用我的服务器要求修改属性。服务器根据访问令牌通过所属组验证角色并调用 Cognito API。该解决方案的问题在于它仅涵盖属性修改场景。
2. 为每个用户池创建一个 AWS Cognito 身份池。对于每个用户池中的每个组，创建一个 AWS IAM 角色，其策略将限制或允许所需的行为。实际上可以工作。该解决方案的问题在于，它感觉像是一个超级骗子的矫枉过正，而且它需要我为每个用户池创建一个额外的身份池和一个 IAM 角色。这意味着加入该服务的每个新客户都需要 (1) 用户池、(2) Cognito 客户端应用程序、(3) 身份池和 (4) IAM 角色（而不仅仅是用户池和 Cognito 客户端应用程序）。本质上，实施此解决方案。

真正的问题：

我是否可以限制某个组中的用户对自己执行操作，例如禁用 MFA（即使用户池的 MFA 设置为“可选”）？

非常感谢大家！任何帮助，将不胜感激！

Answer 1

嗯...经过长时间的研究，我们了解到没有正确的方法。每个可能的解决方案都有其优点和缺点。与 AWS 专家的顾问会议告诉我们：

选项概述：

1. [仅限服务器端] - 我提出的解决方案 #1 与所描述的完全一样。缺点是一样的。它可以工作，并且对用户属性的访问将受到限制。其他客户端将执行的任何其他操作都不会被阻止。
2. [身份池] - 我提出的解决方案#2 是最准确的。然而，我用一个大错误来描述它：一个身份池可以为多个用户池服务！所以本质上，我们只能为每个应用程序的角色创建一个 IAM 角色和一个身份池。然后我们将我们想要的每个用户池匹配到同一个身份池，并在向应用程序引入新角色时 - 只需在用户池中创建一个新组并将其与 IAM 角色匹配。这个解决方案并不像想象的那么复杂，它肯定会成功。作为奖励，您将能够控制和允许访问不同的 AWS 服务。话虽如此，它仍然需要管理和努力。
3. [Post-Auth Lambda] - 这里没有提到的解决方案 #3，我在发布这篇文章后的一天开始工作。我阻止了一个名为“MFA”的新布尔自定义属性的写入权限。它指示用户所需的 MFA 配置。只有服务器可以编辑其值（并且具有 admin 角色的用户将有权访问可以修改它的服务器 API 端点）。我们部署了一个 lambda 函数，该函数将在成功身份验证后触发（Cognito 用户池中的身份验证后触发器）。它将验证经过身份验证的用户所需的和当前的 MFA 配置之间的匹配。如果不匹配，将用户赶出去，因为他做了一些不允许的事情。

*确切地说，我们创建了另一个名为“mfa_status”的自定义属性，并在用户设置其 MFA 配置后设置为 true。lambda 检查 MFA 和 mfa_status 是否都为真，以及当前的真实 MFA 配置是否为假。如果是这种情况 - 用户将被淘汰。

被选中的人或事物：

我们最终选择的解决方案是#3（Post-Auth lambda），因为它是最独立的解决方案。它不需要与我们的服务器或客户端的代码进行任何混合，不需要任何特定于用户池的特殊配置，它仍然允许我们作为客户端继续使用 Cognito 的 Amplify SDK。

谢谢大家的时间，我希望这篇文章能在未来对某人有所帮助。