Identity permissions for a background service with Appsync

Hi Michael,

Thanks for the question. Your backend service typically will assume a role to call AWS AppSync. Take a look at https://read.acloud.guru/backend-graphql-how-to-trigger-an-aws-appsync-mutation-from-aws-lambda-eda13ebc96c3 to see how it can be done. We are also adding multi-auth capabilities to AppSync (https://github.com/aws/aws-appsync-community/issues/1) to support simultaneous backend/frontend callers.

Regards,
Rohan

Thanks for your response and a link to the article- very helpful.

My primary follow-up question is what info will I receive in the $ctx.identity object when an AppSync method is called from the lambda that has a policy to call a specific mutation? Specifically, what logic can I put into a VTL template to know a call is being made from the lambda?

Based on the article it sounds like in order to support both the user and lambda use case, I should create two mutations: one for the user, and another for the lambda, and use IAM policies to permission against those specific mutations. Is there a way to define some information that's part of the IAM Policy may be be read by the VTL template via the $ctx.identity object? Like an OAUTH Scope or Role info? This would let me have a single mutation, and program the conditions on which the mutation can proceed within the VTL.

Thanks,

Mike

Hi Michael,

Yeah, I'd create a separate mutation for the user and for the Lambda. You can scope down the IAM policy so that users can only call the user mutation and Lambda can only call the Lambda mutation, which should be sufficient to guarantee that the user cannot call the Lambda mutation and vice versa. If you want to perform a check in the resolver, the $context.identity (https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html#aws-appsync-resolver-context-reference-identity) has a userArn field, which should contain the role name.

Regards,
Rohan