Escaping AWS IAM Policy Variable for API Gateway Permissions - saml

Question

I currently have SAML integration setup and working as expected between my authentication provider (auth0) and AWS/AWS API Gateway.
The complications arise however when defining an AWS Policy with the ${saml:sub} variable.
Here's an example of my configuration:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:*"
],
"Resource": [
"arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/${saml:sub}"
]
}
]
}
Basically I want to ensure that this endpoint is only accessible by the currently auth'd in user (based on their saml:sub). The currently auth'd user should not be able to access another customers record. Seems like this should be a potentially common use-case.
Auth0 automatically assigns saml:sub and the format of the id is something like this
auth0|429
I'm assuming the issue currently lies with the pipe character being there and it comparing it to an automatically escaped value when the request is made to the API Gateway URL via the browser. Because of this, i'm assuming access is denied to the resource because
auth0|429 != auth0%7C429.
Is there a way within an IAM policy to work around this?
Is there a potential workaround on the Auth0 side to assign a different value to ${saml:sub}?

Answer 1

Appreciate all the potential solutions above! Ultimately I ended up abandoning SAML integration between Auth0 and AWS and opting for a custom authorizer via a lambda function inside of API Gateway. This allowed for a little more flexible setup.
For anyone else facing a similar scenario, I came across this GitHub project that's been working great so far:
https://github.com/jghaines/lambda-auth0-authorizer
I modified the project for our own purposes a little bit, but essentially what we've done is mapped our internal user ID to the AWS principalId.
On the API Gateway side we've setup a /customers/me resource and then on the integration request modified the URL Path Parameters like so:
Integration Request Screenshot
Our policy in our lambda function is setup like so
{
"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"
]
}
]
}
This allows for dynamic access to the endpoint and only returns data specific to the logged in user.

Answer 2

In my opinion the issue you described should be solved/handled from within the AWS Policy configuration, but since I'm not knowledgeable on that I'll offer you a workaround from the perspective of avoiding potential troublesome characters.
You can configure and override the default SAML mappings that Auth0 uses to output user information and as such control the attributes used for each of the output claims and the SAML subject.
Check SAML attributes mapping for an overview on how to do this.
Additionally, check SAML configuration via rules for a detailed view of all the available options.
By default, Auth0 will check the following claims in order to decide the one to be used as the SAML subject:
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

The IAM Policy won't be able to recognize ${saml:sub} in the actual resource ARN. Beyond that, API GW won't automatically understand a SAML assertion.
Are you using a custom authorizer Lambda function to parse the SAML assertion? If so you would want to parse out the 'sub' field and insert it directly into the policy returned from the authorizer like so
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:*"
],
"Resource": [
"arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0|429"
]
}
]
}
If you're already that far and it's still not working as expected, then you're right, it may be that the URI is not being normalized depending on the client/browser encoding. I'd have to test that. But as long as your backend treats /customers/auth0|429 == /customers/auth0%7C429, you could safely build a policy that allows both unencoded and encoded versions of the resource:
{
"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"
]
}
]
}
If you're not using custom authorizers, please elaborate on what your setup looks like. But either way, unfortunately the IAM policy won't ever be able to evaluate the ${var} syntax in the resource block.