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