如何限制 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 客户端应用程序）。 Essentially, implementing this solution.

真正的问题：

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

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

Answer 1

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

选项概述：

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

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

天选之人：

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

感谢大家的宝贵时间，希望这篇文章对以后的人有所帮助。