如何选择最佳策略来使用 AWS Cognito 用户池配置基于角色的授权?

时间:2021-04-17 07:08:24

标签: graphql authorization amazon-cognito aws-amplify

我正在构建一个以 AWS Amplify 作为后端的 Angular 11 应用程序,该应用程序使用 Appsync、dynamodb 和托管 GraphQL API。我正在使用 cognito 用户池进行身份验证。身份验证工作得很好,但我真的很困惑如何进行基于角色的授权。我之前没有使用 Cognito 做过这个,但我有一个理论上应该可行的策略。我想咨询一下是否有更好的方法来做到这一点:-

要求:-

该应用将由我们合作的组织成员使用。每个成员都将与一个组织联系在一起。所以组织有自己的桌子,成员也有。组织的成员只能访问与其组织相关的内容。因此,在身份验证之后,客户端应用程序必须获取当前用户所属组织的 id 以及他们在该组织中扮演的角色,以显示/隐藏 UI 资源和过滤数据。他们可以访问哪些 UI 资源取决于他们在该组织中扮演的角色,当然他们在那里看到的数据必须仅限于与他们的组织相关的内容。

这是我们应用程序的受控测试版,因此 Cognito 用户池使用电子邮件和密码登录。为了简单起见,没有提供其他登录选项。用户注册是不可能的。目前只有管理员可以添加新用户。

我打算如何做:-

  1. Cognito API 已集成到客户端,管理员将添加 来自客户端 UI 的新成员,客户端会将他们添加到 通过 Cognito API 的 Cognito 用户池
  2. 在添加新成员时,管理员将指定哪些 他们所属的组织以及他们在其中扮演什么角色。但该 组织和角色不是存储在 用户池。有一个单独的 dynamodb 表称为“成员” 存储这些信息,因为这些信息会经常变化 并且需要灵活。
  3. 对 Cognito 用户池进行的添加会触发 lambda 函数 自动同步放大中的“成员”表 dynamoDB 表中的后端,其中包含用户池中的新增内容。
  4. 因此,当管理员从客户端 UI 添加新用户时,他们 填写包含电子邮件 ID、姓名、组织和角色的表格 新用户,客户端 UI 将使用名称创建该用户 和用户池中的电子邮件 ID,通过 cognito API。一旦那个请求 返回用户的ID(记住它也会触发创建 通过 lambda 函数在成员表中创建一条记录),我们创建一个 更改成员表,将组织和角色添加到成员表中的用户记录。
  5. Cognito 用户池只有电子邮件 ID、姓名和用户 ID 以及 没有别的,所有其他信息都存储在成员表中, 它也有 ID 和名称(供人类参考),但没有 电子邮件ID。我们不会在 这两个表以避免冗余。
  6. 个人用户可以通过以下方式更新电子邮件 ID 客户端应用程序将通过 cognito 在 cognito 用户池中执行此操作 应用程序接口。并且在发送电子邮件后不需要对成员表进行更新 更新,因为成员表没有电子邮件 ID。所有其他 可以通过客户端应用将成员详细信息添加到成员表中。
  7. 当用户登录时,一旦 Cognito UI 验证 用户并发送电子邮件 ID 和用户 ID,我们获取成员 使用用户 ID 从成员表中获取详细信息,并获取其姓名等详细信息, 他们所属的组织和他们的角色。并使用 有关他们角色的信息,我们可以使用标志限制 UI 资源 在 UI 代码中。为了实现这一点,将有一个单独的表 将让管理员用户修改对每个用户界面资源的访问 角色。所以我们需要获取角色和相关的 UI 标签 身份验证后也是如此。
  8. 至于如何根据组织过滤数据,我不是 还可以,但我想使用一个授权人 使用 graphql 模式本身中的函数指定,这将 获取每个请求的组织 ID 并使用它来过滤 返回给客户之前的数据。

不确定这个过程是否可靠,但这是我能够理解的。如果我这样做是明智的,或者是否有更好的方法来实现我正在做的事情,请告诉我。

0 个答案:

没有答案