我们面临的😔以下问题需要帮助
任何提示将不胜感激！
细节和环境：
- 一个多租户应用程序，旨在为每个客户(组织)提供一个专用租户，以实现完全分离。
- AWS Cognito 用户池 作为用户的数据存储和身份验证提供程序。
- 每个客户(组织)的"AWS Cognito用户池"。
- 角色 管理 - 基于内置用户池组。每个角色和服务器端的组验证用户的访问令牌是否在其嵌入的组列表中包含组名称。
到目前为止一切顺利，一切都按预期工作，使用 AWS Amplify 的开发工具包，用于客户端的实施。Amplify表现良好，允许我做任何我想做的事。服务器验证组归属等。
问题：
我想限制非管理员用户(不属于"管理员"组)通过 Amplify 执行某些 Cognito 操作。 2 示例：
- 我想禁用非管理员用户通过 Amplify 修改特定属性值的功能。
- 我想禁用非管理员用户通过 Amplify 为自己修改 MFA 设置的功能。
当我希望管理员能够为其他用户设置 MFA(启用/禁用)时，实际问题就开始了，但在 Cognito(据我了解)中，只有用户可以设置自己的 MFA 设置。
我看到并已经尝试过：
- 设置用户属性的读/写权限。因此，我想要保护的特定属性只能通过使用开发人员凭据的 API 调用进行修改。这样，管理员可以调用我的服务器来请求修改属性。服务器根据访问令牌通过所属的组验证角色，并调用 Cognito API。该解决方案的问题在于它仅涵盖属性修改方案。
- 为每个用户池创建一个 AWS Cognito 身份池。对于每个用户池中的每个组，创建一个 AWS IAM 角色，该角色具有限制或允许所需行为的策略。实际上可以工作。该解决方案的问题在于，它感觉像是一个超级骗子矫枉过正，而且它要求我为每个用户池创建一个额外的身份池和一个 IAM 角色。这意味着每个加入服务的新客户都需要 (1) 用户池、(2) Cognito 客户端应用程序、(3) 身份池和 (4) IAM 角色(而不仅仅是用户池和 Cognito 客户端应用程序)。本质上，实现此解决方案。
真正的问题：
我是否可以限制特定组中的用户对自己执行操作，例如禁用 MFA(即使用户池的 MFA 设置为"可选")？
非常感谢大家！ 任何帮助将不胜感激！
嗯...经过长期的研究，我们了解到没有正确的方法。每个可能的解决方案都有其优点和缺点。与 AWS 专家的顾问会议告诉我们：
选项概述：
- [仅限服务器端]- 我提出的解决方案#1与描述完全一致。缺点是一样的。它可以工作，并且对用户属性的访问将受到限制。不会阻止其他客户端执行的任何其他操作。
- [身份池]- 我提出的解决方案#2是最准确的解决方案。然而，我用一个大错误来描述它：一个身份池可以为多个用户池提供服务！因此，从本质上讲，我们只能为每个应用程序的角色创建一个 IAM 角色和一个身份池。然后，我们将所需的每个用户池与同一身份池匹配，并且在向应用程序引入新角色时 - 只需在用户池中创建一个新组并将其与 IAM 角色匹配即可。这个解决方案并不像想象的那么复杂，它肯定会解决问题。作为奖励，您将能够控制和允许访问不同的 AWS 服务。话虽如此，它仍然需要管理和努力。
- [后身份验证 Lambda]- 这里没有提到的解决方案 #3，我在发布这篇文章后的第二天开始工作。我阻止了名为"MFA"的新布尔自定义属性的写入权限。它指示用户所需的 MFA 配置。只有服务器可以编辑其值(具有管理员角色的用户将有权访问可以修改它的服务器的 API 终结点)。我们部署了一个 lambda 函数，该函数将在身份验证成功后触发(Cognito 用户池中的身份验证后触发器)。它将验证经过身份验证的用户的所需 MFA 配置与当前 MFA 配置之间的匹配。如果不匹配，请将用户赶出，因为他做了不允许的事情。
*确切地说，我们又创建了一个名为"mfa_status"的自定义属性，并在用户设置其 MFA 配置后将其设置为 true。lambda 检查 MFA 和mfa_status是否都为真，以及实际当前 MFA 配置是否为假。如果是这种情况 - 用户将被抛弃。
被选中的人：
我们最终选择的解决方案是#3(身份验证后lambda)，因为它是最分离的解决方案。它不需要与我们的服务器或客户端的代码进行任何混合，不需要特定于用户池的任何特殊配置，并且它仍然允许我们作为客户端继续使用 Cognito 的 Amplify SDK。
谢谢大家的时间，我希望这篇文章将来能帮助别人。