使用带有或不带有cognito的{awi api网关}的联合身份的轻量级rbac

Question

我无法通过AWS PaaS（gateway / lambda）API看到基于声明或基于角色的授权的良好设计。现在，无论你如何结合以下内容，似乎都有一个功能盲点：

• 网关认知用户池或自定义授权者
• 用于Web和用户池标识联合的cognito标识池
• 网关执行授权的IAM角色

具体来说，盲点似乎是将基于用户属性的认知身份与角色（发电机和s3中的键和后缀更多不同）联系在一起：

• 不需要API中的自定义端点来提供IAM临时信誉（因此使用的不是提供的和/或生成的SDK）
• 在每个lambda函数中都不需要授权逻辑
• 不需要在dynamo，cognito sync等中持久保存上述映射
• 不会对单独的流进行分层或排序以进行授权（例如，单独的令牌）
• 允许您的用户使用外部idps登录

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

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

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

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

Answer 1

• 大多数问题的最简单解决方案是在用户池中（即在auth流中使用Lambda挂钩检查权限，可以从身份验证生成的令牌中检索属性等等），但是您对用户的要求目前不支持使用外部提供商登录。
• 由此，您可以将Cognito联合身份标识与用户池和外部提供程序一起使用，但这会带来一些尴尬。当多个提供者可用时，在用户池中建立特权身份验证lambda挂钩很麻烦，并强制用户池与其他提供者一起使用。
• 从那以后，我会说在一些外部存储中映射权限到身份id是要走的路，使用一些具有该id的外部钩子（Lambda？）来承担角色并获得凭据，但是你提到你不会我想这样做。

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