3
votes

I have my WEB API's hosted in Docker. My Angular client will send a JWT token to access any of these API's. I wanted to make use of AWS API Gateway feature to add an Authorization check before calling the API client requested. From the docs I see that we can leverage the Lambda Authorizer concept to Achieve this. But then again I though why using Lambda Authorizer when I can come up with an DOT NET CORE API which can validate the user.

  1. Does my Lambda Gateway makes sense for my case?
  2. If it does, what would be the output of the lambda Authorizer? A simple true/false which says the the Token is valid or not?

I see that this is what the response should/might look like. How this should translate to in my case

{
              "policyDocument": {
                "Version": "2012-10-17",
                "Statement": [
                  {
                    "Action": "execute-api:Invoke",
                    "Resource": [
                      "arn:aws:execute-api:us-east-1:1234567:myapiId/staging/POST/*"
                    ],
                    "Effect": "Allow"
                  }
                ]
              },
              "principalId": "Foo"
            }
  1. What should happen in API gateway after the Lambda Authorizer executed ? Who calls my actual API which is requested by the client?
4

4 Answers

3
votes

If you are using a Lambda Authorizer, returning an Allow or Deny Policy is what you are looking for.

This essentially grants API Gateway permissions to invoke the underlying target. I know it sounds weird at a first glance, but that's how it works. Think of an Allow policy as a true return statement (credentials matched) kind of thing whilst a Deny policy is more of a false return statement (credentials didn't match / not enough permissions based on your rules, etc).

To get you off ground, you can simply copy/paste the code available at the docs and modify the authentication way to your liking (the docs show an example using a header with Allow or Deny values, which is definitely not what you want, that's just meant for the sake of an example).

So, back to your question by enumerating all the answers:

  1. Yes, but it's called a Lambda Authorizer instead of a Lambda Gateway
  2. Either an Allow or Deny policy for valid/invalid tokens respectively.
  3. If the Lambda Authorizer responds with an Allow policy, it will then invoke the target (which can be a Lambda function, an SNS Topic, an HTTP endpoint - this is likely your case - and so on). The authorizer will just act as an interceptor and decide whether to proxy the call to the target or not.
0
votes

From what I understood as per the question, you want to validate the user who are calling your API.

You can do it in all the ways you have already mentioned. Using Lambda Authorizers, you will get a 200 or a 403 code not true false. You can follow the following link to set up your authorizer :

https://blog.codecentric.de/en/2018/04/aws-lambda-authorizer/

You can also use AWS Cognito for managing your users, it'll simplify your work a lot.

0
votes

You just add your dotnet core api to "Integration Request" tab, Choose Integration type as HTTP and mention the dotnet core api in Endpoint URL field

-1
votes

Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0.

Advantages for using Cognito: Managed service, less components to implement/monitor/scale

Easily configurable via portal, CLI and templates

Supports multiple flows for authentication (client side, server side, OAuth2, custom)

Supports Lambda triggered functions on authentication/registration events

Uses JWT signed tokens which can be passed directly to clients in session cookies and used to verify requests and passed in related API calls so a single authentication/authorisation method can be used through your stack statelessly Group membership, supplied in access token can be used for authorisation (e.g. users in group “Admin” can perform admin functions)

Handles:

  • User group membership and attribute storage

  • Email/Phone verification

    • User invitation

    • Login/Signup UI forms (customisable)

    • Password reset

Disadvantages:

  • Less control over authentication/authorisation (limits to UI/flow customisation)
  • Potential for lock-in (cannot export users with passwords for migration)
  • Amazon Cognito has three type of authorizer
  • Amazon Cognito user pool - User pool authorizer.
  • Amazon Cognito federated identities - AWS IAM Authorization.
  • Custom Lambda identity providers - Custom Autorizer

enter image description here