使用带或不带 cognito 的 aws api 网关的联合身份的轻量级 rbac

Posted 2023-03-27

【中文标题】使用带或不带 cognito 的 aws api 网关的联合身份的轻量级 rbac

【英文标题】：lightweight rbac for federated identities using aws api gateway with or without cognito

【发布时间】：2017-01-07 08:59:19

【问题描述】：

我看不到通过 AWS PaaS（网关/lambda）API 进行基于声明或基于角色的授权的良好设计。现在，无论您如何组合以下内容，似乎都存在功能盲点：

网关认知用户池或自定义授权者 用于网络和用户池身份联合的认知身份池 网关执行授权的 IAM 角色

具体而言，盲点似乎是基于用户属性将认知身份与角色（比 dynamo 和 s3 中的键和后缀更多样化）相关联，其方式如下：

不需要在您的 API 中使用自定义端点来出售 IAM 临时凭据（因此使用提供和/或生成的 SDK 以外的其他东西） 不需要在每个 lambda 函数中都有授权逻辑 不需要在 dynamo、cognito sync 等中保留上述映射 不对单独的授权流进行分层或排序（例如单独的令牌） 让您的用户使用外部 idps 登录

我认为以下是不可能的或过于hacky：

认知用户池重叠或在池之间移动用户以表示其角色配置 直接从 congito 身份池身份令牌（GetOpenIdToken）获取 cognito 用户池属性 让易于修改的客户端选择自己的权限（例如选择 IAM 角色） 在自定义授权方或其他影子实现 IAM 中以空运行方式运行每个请求 使用某种共享密钥等来保护特定于角色的 IAM 角色。

以下是一些示例及其缺点：

用户使用用户池凭据登录并尝试执行网关 api 方法。
通过网关 API 方法的 cognito 授权器可以让我说 autheticated-therefore-authorized 并将属性/声明映射到集成请求中，仍然将其留给 lambda 函数来实现实际的授权逻辑。 自定义授权方不会自动验证和解析用户池令牌，但我仍然可以这样做并有条件地构造一个角色。
用户使用 google+ 凭据登录，同时拥有用户池身份，并尝试执行网关 api 方法。
认知授权者是无用的。 自定义授权方不会自动验证和解析 google+ 令牌，但我仍然可以这样做并有条件地构造一个角色。只是现在我需要手动将其映射到用户池身份。 Cognito 在这里根本没有增加任何价值 - 只是一个笨拙的文档数据库即服务。
用户使用 google+ 凭据登录，同时拥有用户池身份，然后获取身份池令牌 (GetOpenIdToken) 并尝试执行网关 api 方法。
认知授权者是无用的。 自定义授权方不会自动验证和解析 cognito 身份令牌，但我仍然可以这样做并有条件地构造一个角色。我仍然需要进行手动映射，因为我不会使用此中间令牌获取用户池属性。
用户使用 google+ 凭据登录，同时拥有用户池身份，然后获取临时凭据 (GetCredentialsForIdentity) 并尝试执行网关 api 方法。
默认授权者无用。您只需获得身份验证-因此-授权。 认知授权者是无用的。 自定义授权者没有用。

【参考方案1】：

大多数这些问题的最简单的解决方案是在用户池中（即在身份验证流程中使用 Lambda 挂钩来检查权限，可以从身份验证生成的令牌中检索属性……等等），但是您要求用户目前不支持可以使用外部提供商登录。 由此，您可以潜在地将 Cognito 联合身份与用户池和外部提供商一起使用，但这会带来一些尴尬。当有多个提供程序可用时，将权限身份验证构建到用户池 lambda 挂钩中很尴尬，并且会强制将用户池与其他提供程序一起使用。 因此，我想说将权限映射到某些外部存储中的身份 ID 是可行的方法，使用带有该 ID 的一些外部挂钩（Lambda？）来承担角色并获取凭据，但您提到您不会想要这样做。

我同意您的目标并非绝对可能。我的建议可能是与 SA 联系，看看他们是否可以帮助您设计满足您要求的复杂解决方案。