Configurei um REST API Gateway que fornece serviços via integração Lambda. Esta API é protegida por um autorizador AWS Lambda, que valida se o token JWT passado como cabeçalho na solicitação é válido ou não. Isso significa que apenas usuários registrados com tokens JWT válidos podem chamar esta API. No entanto, além de usuários->API, também precisamos fornecer comunicação sistemas->API que não deve depender de "usuários do sistema" para chamar a API.
Até agora configurei todos os meus recursos no API Gateway para usar a função Lambda Authorizer como método de autorização, isso atende ao fluxo de comunicação usuários-> API.
Para a comunicação sistemas->API, estava pensando em permitir a comunicação via IAM Roles. A ideia é que os sistemas possam assumir uma função AWS e assinar as solicitações HTTP usando AWS SigV4. Dessa forma, eu poderia usar políticas de recursos do gateway da API REST para permitir ou negar o acesso dos sistemas à API por meio de políticas da AWS (validando funções específicas como principais), mas isso exigiria ignorar a autorização lambda para este caso de uso.
A documentação da AWS não é clara sobre as opções para esta combinação de casos de uso. Parece que para a autorização de funções IAM por meio de políticas de recursos, eu precisaria alterar as configurações de recursos do API Gateway para usar AWS_IAM como método de autenticação em vez de LAMBDA. Embora os documentos mencionem a possibilidade de combinar políticas de recursos de API e autorizador Lambda, isso só parece aplicável para bloquear solicitações que não sejam provenientes de um VPC ou intervalo de IP específico ( link ).
Em resumo, o que quero alcançar é algo como:
User's requests --(JWT)--> Lambda Authorizer ---|
(Identity via Oauth) |
|-> API Gateway
System's requests --(SigV4)--> Resource Policy --|
(Identity via IAM Role)
Portanto, não encontrei uma maneira de ter ambos os fluxos de autorização para meus dois casos de uso separados de maneira exclusiva. Descobri que só posso ter um para cada endpoint de recurso do API Gateway.
Alguém sabe se meu objetivo pode ser alcançado usando REST API Gateways? Caso contrário, existem outras alternativas para este problema?
Na verdade, você só pode ter um autorizador por método e por recurso, portanto é impossível fazer exatamente o que você procura.
O que você pode fazer é criar e manter dois API Gateways com o mesmo conjunto de recursos, métodos e integrações, mas autorizadores diferentes: um para seus usuários, outro para os sistemas.
Outra opção seria manter seu próprio conjunto de chaves de API (não aquelas que vêm com o Gateway, mas autogerenciadas, como registros no DynamoDB ou algo parecido) e verificar o JWT ou essas chaves no autorizador personalizado.
Isso exigirá trabalho adicional: você terá que descobrir como criar, armazenar, distribuir, verificar e revogar essas chaves, o que é definitivamente mais difícil do que apenas criar uma função usando o console AWS e assumi-la pelo seu serviço.
Um serviço para verificar assinaturas V4 para determinadas funções é uma solicitação popular, que ajudaria você a resolver seu problema se a AWS o fornecesse.