feat: http api - iam authorizer

[iRoachie]

Last outstanding authorizer for http apis.

resolves #10534

Not totally sure if we should include the bit inside integ.iam.signature but I added it as a way to test the integ stack.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[iRoachie]

cc @nija-at How should I go forward with the testing bit? The build fails right now because of the linting done on all package.json files

[nija-at]

See my comment below.

[nija-at]

Hi @iRoachie -

This does not feel like the right approach to solving IAM authorizers. Just having an HttpIamAuthorizer class to set the AuthorizationType and then leaving it up to the user to correctly configure the IAM policy feels sub-optimal.

I would suggest going with an alternate approach. Here's my proposal written in the form of what the user experience will be -

const api = new HttpApi(stack, 'HttpApi');
const routes: Route[] = api.addRoutes({ ... });
routes[0].grantInvoke(principal, { // principal is of type iam.IPrincipal
  httpMethod: 'GET'
});

This should, under the hood, automatically set the AuthorizationType to AWS_IAM and attach the relevant IAM permissions to the principal.

[iRoachie]

I was going based on usage and what was requested in #10534.

As far as I understand the use case for IAM Authorization is to set policies on individual users to grant access to all/some routes.

I see where you are going with your suggestion however I think this can be an add-on to what is currently in this PR. If we only change the authorizationType when grantInvoke is called on a route then we automatically rule out scenarios where user permissions are managed outside of cdk/cloudformation (which is pretty common for physical users).

So just to be clear they're two things here:

1. Setting route to use IAM Authorization
2. Allowing an easy way to assign the relevant policies to a user/principal so that it can invoke that route.

Pull request has been modified.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 39d3d6e
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[misterjoshua]

Hey all. What's needed to move this PR forward?

[iRoachie]

@misterjoshua i’m a bit unsure how to go through with integration tests. I added an example which generates an AWS signature to attach to the request to simulate a real environment.

this fails the lint because of the additional package.json file.

[misterjoshua]

@misterjoshua i’m a bit unsure how to go through with integration tests. I added an example which generates an AWS signature to attach to the request to simulate a real environment.

this fails the lint because of the additional package.json file.

@iRoachie I have taken a crack at fixing the integration tests. My branch is here: https://github.com/misterjoshua/aws-cdk/tree/ft/http-api-iam-authorizer

Some notes:

• I used python instead of node so that I could work around that package.json complaint.
• Instead of running the signing locally, I ran it in lambdas.
• I also switched the unit tests over to use @aws-cdk/assertions

Let me know your thoughts.

[iRoachie]

@misterjoshua Awesome job. Apologize I didn't have the time.

[misterjoshua]

@misterjoshua Awesome job. Apologize I didn't have the time.

No worries. Thanks for getting the boulder rolling!