转义 API Gateway 权限的 AWS IAM 策略变量答案

【问题标题】：Escaping AWS IAM Policy Variable for API Gateway Permissions转义 API Gateway 权限的 AWS IAM 策略变量
【发布时间】：2017-01-06 12:54:14
【问题描述】：

我目前有 SAML 集成设置，并且在我的身份验证提供程序 (auth0) 和 AWS/AWS API Gateway 之间按预期工作。但是，使用 ${saml:sub} 变量定义 AWS 策略时会出现复杂情况。

这是我的配置示例：

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "execute-api:*"
        ],
        "Resource": [
            "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/${saml:sub}"
        ]
    }
]

}

基本上，我想确保此端点只能由当前经过身份验证的用户访问（基于他们的 saml:sub）。当前经过身份验证的用户应该无法访问其他客户记录。看起来这应该是一个潜在的常见用例。

Auth0 自动分配 saml:sub 并且 id 的格式是这样的

auth0|429

我假设问题目前在于管道字符存在，并且当通过浏览器向 API Gateway URL 发出请求时，它将它与自动转义的值进行比较。因此，我假设对资源的访问被拒绝，因为 auth0|429 != auth0%7C429。

IAM 策略中是否有解决此问题的方法？ Auth0 端是否有潜在的解决方法来为 ${saml:sub} 分配不同的值？

【问题讨论】：

标签： saml amazon-iam aws-api-gateway auth0

【解决方案1】：

欣赏以上所有潜在的解决方案！最终，我放弃了 Auth0 和 AWS 之间的 SAML 集成，并通过 API Gateway 内的 lambda 函数选择了自定义授权方。这允许更灵活的设置。

对于面临类似情况的其他人，我遇到了这个 GitHub 项目，该项目到目前为止运行良好： https://github.com/jghaines/lambda-auth0-authorizer

我出于我们自己的目的稍微修改了项目，但基本上我们所做的是将我们的内部用户 ID 映射到 AWS principalId。

在 API 网关端，我们设置了 /customers/me 资源，然后在集成请求中修改了 URL 路径参数，如下所示： Integration Request Screenshot

我们在 lambda 函数中的策略是这样设置的

{ "Version": "2012-10-17", "Statement": [ { "Sid": "324342", "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/me" ] } ] }

这允许对端点进行动态访问，并且只返回特定于登录用户的数据。

【讨论】：

那么您使用的是哪个端点：/customers/{id} 或 /customers/me？看来，如果您在集成请求中使用带有身份的 /me，那么您就不需要 /{id} 端点，对吧？
很抱歉给您带来了困惑。是的 - 我们使用 /customers/me 而不是 customers/{id} 作为资源。我已经更新了答案以反映这一点。

【解决方案2】：

在我看来，您描述的问题应该在 AWS 策略配置中解决/处理，但由于我对此并不了解，因此我将从避免潜在麻烦字符的角度为您提供一种解决方法。

您可以配置和覆盖 Auth0 用于输出用户信息的默认 SAML 映射，从而控制用于每个输出声明和 SAML 主题的属性。

查看SAML attributes mapping 了解如何执行此操作的概述。

此外，请查看SAML configuration via rules 了解所有可用选项的详细信息。

默认情况下，Auth0 将检查以下声明，以确定用作 SAML 主题的声明：

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

【讨论】：

【解决方案3】：

IAM 政策将无法识别实际资源 ARN 中的 ${saml:sub}。除此之外，API GW 不会自动理解 SAML 断言。

您是否使用自定义授权方 Lambda 函数来解析 SAML 断言？如果是这样，您可能希望解析出“子”字段并将其直接插入到授权方返回的策略中，如下所示

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "execute-api:*"
        ],
        "Resource": [
            "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0|429"
        ]
    }
  ]
}

如果您已经到了这么远，但仍然无法按预期工作，那么您是对的，可能是 URI 没有根据客户端/浏览器编码进行规范化。我必须对此进行测试。但只要您的后端处理/customers/auth0|429 == /customers/auth0%7C429，您就可以安全地构建一个允许资源的未编码和编码版本的策略：

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "execute-api:*"
        ],
        "Resource": [
            "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0|429",
            "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0%7C429"
        ]
    }
  ]
}

如果您不使用自定义授权方，请详细说明您的设置是什么样的。但无论哪种方式，不幸的是，IAM 策略永远无法评估资源块中的 ${var} 语法。

【讨论】：