Question

我目前正在进行SAML集成设置，并在我的身份验证提供程序（auth0）和AWS / AWS API网关之间按预期工作。但是，在使用$ {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}"
        ]
    }
]

}

基本上我想确保此端点只能由当前auth'd in用户访问（基于他们的saml：sub）。当前已授权的用户不应该能够访问其他客户记录。看起来这应该是一个潜在的常见用例。

Auth0自动分配saml：sub，id的格式是这样的

auth0|429

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

在IAM政策中有办法解决这个问题吗？在Auth0方面是否有可能为$ {saml：sub}分配不同的值？

Answer 1

欣赏上述所有潜在的解决方案！最终，我最终放弃了Auth0和AWS之间的SAML集成，并通过API网关内部的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" ] } ] }

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

Answer 2

在我看来，您所描述的问题应该在AWS Policy配置中解决/处理，但由于我对此不了解，我会从避免潜在麻烦角色的角度为您提供解决方法。

您可以配置和覆盖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

Answer 3

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

您是否使用自定义授权程序Lambda函数来解析SAML断言？如果是这样，你会想要解析＆＃39; sub＆＃39;字段并将其直接插入从授权器返回的策略中，如此

{
"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}语法。

为API网关权限转义AWS IAM策略变量

3 个答案: