Я внедряю решение в AWS, когда локальные клиенты (производители) отправляют сообщения в очередь AWS SQS.
Временные учетные данные AWS IAM используются AWS для аутентификации клиентов при вызовах API SQS (Sigv4).
Приложение потребителя в AWS, которое обрабатывает сообщения из очереди, должно идентифицировать (на сообщение) принципала клиента (производителя сообщений).
Поскольку клиенты уже используют временные учетные данные AWS STS для вызова AWS STS, я подумал о том, чтобы повторно использовать эти учетные данные для подписи (Sigv4) создаваемых им сообщений, чтобы потребитель приложения мог аутентифицировать и идентифицировать клиента.
Подписание сообщения выполнимо, но как тогда потребитель приложения может определить принципала клиента и проверить его подпись?
Для этого потребитель приложения должен иметь доступ к:
1) Соответствующий секретный ключ доступа AWS (для вычисления подписи HMAC)
2) Соответствующий участник AWS STS, связанный с учетными данными
Как AWS реализует то же самое в API-шлюзе, например (API-шлюз не только проверяет подпись, но и распространяет принципал)?
Если не существует более простого способа проверить подписанные сообщения SQS (sigv4) и распространить принципал, я рассмотрю следующие меры:
1. Используйте API-шлюз в качестве внешнего интерфейса для AWS Lambda, который отправляет сообщение в AWS SQS (AWS выполняет аутентификацию и распространение принципала)
2. Ввести API-интерфейс приложения STS, который создает временные учетные данные AWS STS и сохраняет идентификатор ключа доступа + секретный + принципал в базе данных таким образом, чтобы они были доступны для приложения-потребителя SQS, которое позже проверяет сигнатуры сообщений sigv4 и считывает значение принципала из база данных.