I am implementing a solution on AWS where clients (producers) on-premise are sending messages to AWS SQS queue. AWS IAM temporary credentials are used by AWS to authenticate clients on SQS API calls (Sigv4).
The consumer application on AWS that process messages from the queue has to identify (per message) the principal of the client (message producer).
Since clients already use AWS STS temporary credentials for making the call to AWS STS, I thought to reuse these credentials for signing (Sigv4) the messages they produce such that the application consumer can authenticate and identify the client.
Signing the message is doable, but then how the application consumer can identify the principal of the client and verify its signature? To do that, the application consumer has to have access to: 1) The corresponding AWS Access Key Secret (for computing HMAC signature) 2) The corresponding AWS STS principal associated with the credentials
How does AWS implement the same in API Gateway for example (API Gateway not only verify the signature but also propagate the principal)?
If there is no simpler way to verify the signed SQS messages (sigv4) and propagate the principal, these are the mitigations I am considering: 1. Use API Gateway as a frontend to AWS Lambda, which sends a message to AWS SQS (authentication and principal propagation are both addressed by AWS) 2. Introduce an application STS API that produces AWS STS temporary credentials and persists the access key ID+Secret+Principal in a database such that they are available to the SQS consumer application that later on validates the sigv4 message signatures and read the principal value from the database.
