feat(apigatewayv2): http api - IAM authorizer support

[misterjoshua]

Fixes #15123

See also: @nija-at's comments on grantInvoke, #10534

---

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

[gitpod-io]

[pahud]

Hi @ChenKuanSun can you take a look?

[bracki]

Looking at the docs it is unclear to me how to just turn on IAM for the whole API. Also I don't understand why it's not an "authorizer", as in the Rest API gateway. Personally I think that the use case of bringing your own policy/role is more often the case then the "grantInvoke", but that's a gut feeling.

Currently I'm solving this problem with:

    // Enable IAM authentication
    routes.forEach((route) => {
      const r = route.node.defaultChild as CfnRoute;
      r.authorizationType = AuthorizationType.IAM;
    });

[nija-at]

This is starting to look interesting. See my initial comments below.

Pull request has been modified.

[misterjoshua]

Looking at the docs it is unclear to me how to just turn on IAM for the whole API. Also I don't understand why it's not an "authorizer", as in the Rest API gateway. Personally I think that the use case of bringing your own policy/role is more often the case then the "grantInvoke", but that's a gut feeling.

Currently I'm solving this problem with:

    // Enable IAM authentication
    routes.forEach((route) => {
      const r = route.node.defaultChild as CfnRoute;
      r.authorizationType = AuthorizationType.IAM;
    });

@bracki Good point. Since my initial PR, Nija has suggested adding HttpIamAuthorizer, so now you should be able to turn on IAM for the whole API by specifying a default authorizer in the HttpApi.

[otaviomacedo]

[minor] Now that key can be derived from the other two attributes, I would remove it from the constructor to make it cleaner and avoid mistakes.

[misterjoshua]

I've now simplified this section so that it's cleaner and easier to avoid mistakes. As far as I can see, HTTP API has only the $default and METHOD /path/here formats for key, so this should work. https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-routes.html

Let me know whether this change works for you.

Pull request has been modified.

[misterjoshua]

@otaviomacedo I got a notification for the following message but I can't find it anywhere to reply to it. I'll respond here in the comments:

I think this is the last point we need to work out. I'd rather have all authorizers in the -authorizers module. What's your idea here? How would you avoid the circular dependency?

Right now I've allowed grantInvoke to configure IAM via authorizer by implementing the authorizer in the main package. But yes, I can see that this makes the IAM authorizer the odd one out.

It seems to me that if the IAM authorizer must be in the other package, the circular dependency arises from adding the authorizer automatically when the user calls grantInvoke.

If we resolve this conflict by removing the route's responsibility to configure IAM authorization, we can relocate the IAM authorizer and there will be no circular dependency problem.

All things being equal, I'd prefer to remove the route's responsibility to configure IAM from grantInvoke as it could simplify the Lazy props.

What do you think?

[otaviomacedo]

If we resolve this conflict by removing the route's responsibility to configure IAM authorization, we can relocate the IAM authorizer and there will be no circular dependency problem.

I agree. So, two questions:

1. Where would you move that responsibility to?
2. What would the API look like?

[misterjoshua]

1. Where would you move that responsibility to?

@otaviomacedo We'd require that the user specify the authorizer they want in the construct's props as they do now.

2. What would the API look like?

It would look the same as it does now in the README, however, it differs in one case: When the user omits the IAM authorizer and calls grantInvoke, we should probably throw an error. This effectively undoes "If grantInvoke is called, you can set this automatically."

[otaviomacedo]

Yes, the only downside is that, if someone provides a different authorizer, grantInvoke would do nothing (I believe) and they would only find out at runtime. But I think it's a reasonable compromise.

[otaviomacedo]

Well done! Thank you.

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: fb51b90
• Result: SUCCEEDED
• Build Logs (available for 30 days)

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

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).