【问题标题】:Highly granular access control of non-AWS resources in AWS CognitoAWS Cognito 中对非 AWS 资源的高度精细访问控制
【发布时间】:2018-10-25 15:02:56
【问题描述】:

我有一个使用 AWS Cognito 进行身份验证和资源访问控制的 ASP.NET Web API。到目前为止,我们一直在使用用户池组来定义用户可以访问的某些实体(数据库中的非 aws 资源)。

问题是,现在我们对访问控制的要求更加详细,我们达到了每个池 25 个组的上限。我研究了 Cognito 中的替代方案,例如使用自定义属性,但我发现每个池的自定义属性数量也有限制,而且它们只支持字符串和数字类型,而不支持数组。

我探索的另一种替代方法是在令牌到达我们的 API 时拦截它,并根据数据库中映射的权限添加声明。这工作得相当好,但这只是一个解决方案服务器端,我对需要拦截每个请求以通过数据库调用添加声明并不完全兴奋(对性能来说不是很好)。我们还需要一些这样的声明客户端,所以这不是一个很好的解决方案。

除了请求增加每个池可用的组数量的服务限制之外,我是否遗漏了任何明显的东西?根据 AWS 的文档,组似乎是建议的方法。即使我们采用具有多个池的多租户方法,我认为 25 个组的上限仍然是一个问题。

https://docs.aws.amazon.com/cognito/latest/developerguide/scenario-backend.html

【问题讨论】:

  • 您可以申请提高限额吗?

标签: amazon-web-services amazon-cognito


【解决方案1】:

您几乎可以为服务的任何部分请求增加限制。他们会考虑的。正如您所指出的,有时这比构建辅助系统更简单。见https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html

【讨论】:

  • 我已经请求增加服务器限制,但我确实想确保我没有遗漏一些明显的东西,因为我们预计规模相当大,我希望避免在未来遇到限制.
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2022-01-03
  • 1970-01-01
  • 2021-07-14
  • 2019-05-16
  • 1970-01-01
  • 2016-12-02
  • 1970-01-01
相关资源
最近更新 更多