Run Lambda function with same permissions as user invoking API Gateway endpoint - amazon-web-services

I have the following setup:
REST API Gateway containing one endpoint with a proxy Lambda integration and secured using the AWS_IAM authorizer. End users retrieve temporary AWS credentials from a Cognito Identity Pool in exchange for tokens retrieved from a Cognito User Pool and then call the API using these credentials.
When users call the API Gateway, I want the invoked lambda function to run with the same permissions as the invoking user. For example, if the user only has the permission to read items from DynamoDB with a PK of CUSTOMER1234, I want the lambda function to also only have that permission. Different users will have different permissions so I can't "hard-code" that into my Lambda permissions.
This seems like a fairly common use case, but I was unable to find any documentation on how to achieve something like this.
One possibility would be to send the AWS credentials (i.e. access key and secret key) of the user with every request and then construct a new session using these credentials in the Lambda, but this probably is a terrible idea (it also increases function runtime by 5x).

It doesn't seem like a good idea to send AWS credentials over the network, as there is the chance that they could be intercepted by an attacker and used to access your resources until they expired.
It could be possible to use the JWT from your Cognito User Pool to get the AWS credentials in the lambda function e.g. using:
AWS.config.credentials = new AWS.CognitoIdentityCredentials({
IdentityPoolId: 'IDENTITY_POOL_ID',
Logins: {
'cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>': 'ID_TOKEN'
}
});
This would mean that your lambda's API calls would run using the role mapped to in your identity pool, and you could use the LeadingKeys condition to ensure that your web identity could only access their own data:
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
}
}
However, this would add processing time because you are making extra API calls (CognitoIdentityCredentials() makes 2 API calls behind the scenes) on every request to get the credentials. Plus, you couldn't use the AWS_IAM authorization on your API Gateway method because you won't have got the credentials yet. So you are then talking about having a two authorization setups. One to allow your web identity to call the API Gateway method, and a second for your Lambda function to run as your user.
So perhaps your choices are:
Make your API calls direct from your client
Instead of going via API Gateway, you could make the DynamoDB API calls directly from the client. This would work well with your Identity Pool setup, as you can make the CognitoIdentityCredentials() call just once when the user logs in to get the AWS credentials. The subsequent DynamoDB calls would then be made with your user permissions and you could use the LeadingKeys condition to ensure that your user only accesses their own data.
Accept that your lambda function will always run with the same execution role
If you want to use API Gateway backed with Lambda, then you could just accept that you will use Lambda or Cognito Authorizers to authorize your users have permissions to execute the API method, and then some further application-level authorization in the Lambda function to ensure they only call their own partition space. In fact, this way you might not need the Identity Pool, but rather just use the sub claim from the User Pool JWT token. After all, you will have validated the JWT containing the sub hasn't been tampered with, and that it was issued by the correct user pool and application client, so you can trust its contents.
You could integrate API Gateway directly with DynamoDB
Depending on your required logic, rather than have your API method backed by a lambda function you could integrate your API Gateway method directly with DynamoDB as shown in this amazon tutorial. Again, you would use the sub from the validated JWT as the partition key to enforce the correct data access.

Related

using api gateway with aws cognito for protected routes

So I'm going to put a public facing API up using AWS API Gateway, where I'll have back end lambda resources that handle the logic for each route (decoupled microservice).
What should I be storing in the JWT? Currently, I've disabled all read attributes, so the token only contains cognito:username, where in my database I will store this as the user id for each user. My understanding is that once a JWT is properly generated, I can use Cognito as an authorizer with API Gateway, and then once the token JWT details are received at the lambda layer, all I need to do is use the cognito:username key to lookup the user profile in my database.
Should I be implementing any other checks in the backend, or is it safe to rely on API gateway to pass the authenticated request?
Thanks!
The cognito API Gateway authorizer will only check if the token has not expired and if it belongs to the correct user pool. But since you will be extracting username from the token itself, you should be safe. Just make sure to configure API Gateway to pass Authorization header to the lambda, it does not do this by default.

Testing Cognito user pool auth with API gateway

I would like my client application to insert records in my dynamoDb instance using API gateway secured with Cognito user pools.
I have created my user pool and added it as an authorizer to my API gateway method call. Using AWS Cli I ran the following command which gave me my access token:
aws cognito-idp initiate-auth ...
My infrastructure seems to be working, now which direction do I need to go to pragmatically achieve signing-in as my user in the user pool, grabbing the token and calling my API method?
Well it's not difficult. You need to follow certain steps.
Create an user in Cognito user pool. Confirm it, by the means of activation message you have chosen. It can be sms or email as per the user pool settings.
After you confirm the user, you need to call the login API from Cognito SDK. Since I am comfortable in NodeJS, let me grab the method name - https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html. Set AuthFLow to ADMIN_NO_SRP_AUTH .The response from this APi will have one idToken, one accessToken and one refreshToken. Since you need these credentials at your client, write an API in your preferred language, expose it your client and return the tokens.
Use the idToken to make API calls to your API Gateway Authorizer. This is how you pass the token using Postman -
You can replicate the same using any client. If you face any error, It'd be better if you show me your APIG authorizer configuration.

AWS API Gateway Custom Authorizer: create IAM Policy for Unauthenticated Session

I have a GraphQL API Gateway endpoint which sits behind a custom authentication function which I’d like to also allow certain endpoints for consumption by ‘unauthenticated’ users (for which my Cognito User Pool allows).
Currently, the custom authenticator only caters for Cognito authenticated sessions. This function validates the Cognito token passed from the client (as per this logic), generates an IAM Allow Policy and then passes this to the GraphQL function.
I can generate the unauthenticated session on my clients using the Amplify library and attaching the sessionToken as my ‘Authorization’ header value:
Auth.currentCredentials().then((credentials: ICredentials) => {
this.unauthenticatedCredentials = credentials; // credentials.sessionToken
});
However, passing this through my custom authorizer as is throws an error token is expired.
According to the Cognito token deserializer (link above), the claims expiration date: <5 days ago (tested after clearing local storage).
If this is possible, how can I generate an Allow Policy and get Claim based off an unauthenticated user session?
Note: I’ve seen the option to create a secondary identical GraphQL endpoint which serves functions I want to allow with no authentication, but I was trying to avoid it as it seems architecturally wrong.

Use custom authorization logic with AWS Cognito authentication

We have a Cognito User Pool which contains the users we would like to allow access to, to our API. Our API uses Lambda functions to service the endpoints. The Cognito pool is configured with a custom field roles which is essentially a comma-separated list of roles that user possesses.
Now, first, we want the Cognito authentication to take place (to determine whether the user does belong to our pool and the credentials are valid). Then, we somehow want to run our custom logic to run which will look at the roles field which it will receive through the claims, and then allow or deny the request based on internal business logic.
We tried using a custom authorizer to implement this logic and set it as the authorizer for our endpoints. Then, we enabled Cognito authorization for this authorizer function. The problem is that since Cognito protects API endpoints and not lambda functions per se, the Cognito authorization simply does not run when an API endpoint is hit and the custom authorizer is called.
How do we achieve our objective of using custom logic with Cognito authorization? Any help in this regard would be highly appreciated.
All of the claims in the users' token are available in the context that can be passed to your lambda function if you are using cognito authorizers under $context.authorizer.claims.property Would mapping that claim into your lambda function and checking that the roles is present at the beginning of your lambda work for you?

AWS Lambda, API gateway & Cognito: How to get the identity object in lambda function?

Im building a serverless backend using the following AWS technologies:
AWS api_gateway
AWS cognito
AWS lambda
In api_gateway I have created a Cognito User Pool authorizer and Im using this authorizer for all requests to the backend.
Everything works: When a user makes a request with an invalid JWT token, the server respons accordingly. A valid JWT token executes the requested Lambda function.
Problem: I'm unable to retrieve identity information, such as accessKey, accountId, cognitoIdentityId and so forth. All these variables are null when I access them via the context object in the lambda function
Question: What do I need to do in order to get the identity variables?
The context object in the Lambda function contains the context from Lambda's perspective. The Lambda function is running with the identity of it's execution role, thus its context won't contain the identity attributes from the Cognito user pool.
API Gateway exposes the Cognito user pool identity information via $context.authorizer.claims variable within API Gateway. To access this information from within your Lambda function, you must modify your body mapping template in API Gateway to pass the desired data from $context.authorizer.claims to your Lambda function via the request body. You're Lambda function then reads this information from the request body like any other field.
Documentation on this can be found here.
Scroll down to the section titled "To enable a user pool authorizer on methods" and see step 7: "If needed, choose Integration Request to add $context.authorizer.claims ..."
When you created the Cognito User Pool you would have created two IAM Roles. You can now setup API Gateway to pass the Identity information by
Authorization set to AWS_IAM
Turn on Invoke with caller credential
In Lambda you should be able to get the information in context.
Note: In the Cognito IAM Roles you need allow invoke permission for API Gateway.