Controle de acesso centralizado no Serasa eCred
Se você usa a nuvem da Amazon e precisa controlar o acesso aos recursos do seu produto, esse artigo pode lhe ajudar a simplificar o fluxo de autorização de usuários através da experiência do Serasa eCred.
Autorização no Serasa eCred
O eCred é o marketplace de crédito da Serasa, o objetivo é oferecer a melhor experiência na hora de buscar um cartão e/ou empréstimo para consumidores brasileiros.
Ao entrar na plataforma, o consumidor recebe um token de acesso válido por um determinado tempo. A validade e a expiração do token são gerenciadas pela API de sessão da Serasa.
Integração com lambda como proxy
Alguns endpoints do API Gateway usavam a integração de lambda como proxy, a lambda era responsável por autorizar e encaminhar o acesso aos nossos serviços, além de converter rotas e mapear parâmetros configurados em um banco sqlite.
A solução funcionava bem, mas tinha muitas responsabilidades e alguns problemas:
- Risco de registros inválidos corromperem o arquivo binário armazenado pelo sqlite.
- Revisão de código complicada, como não dava para saber quais registros foram alterados, tínhamos que baixar o repositório da lambda e abrir o arquivo em uma ferramenta gráfica para conferir o estado do banco.
- Erros de throttling em picos de acesso devido ao aumento no tempo de resposta dos serviços do eCred.
Bibliotecas compartilhadas
Para diminuir o problema de throttling, removemos a lambda proxy dos endpoints mais usados e configuramos a integração diretamente com os serviços.
Esses serviços usavam bibliotecas compartilhadas com a mesma lógica de autorização da lambda.
O erro de throttling sumiu, mas deixou alguns custos:
- Replicar a implementação do fluxo de autorização em cada nova linguagem adotada.
- Manter a versão atualizada nos serviços que dependem das bibliotecas.
- Além de se preocupar com as regras de negócio, o desenvolvedor também precisava se preocupar com autorização no seu serviço.
Problemas com as soluções
Os endpoints antigos continuaram com o lambda-proxy e os novos compartilhando bibliotecas.
A falta de padronização gerava confusão e uma sensação de estar esquecendo alguma configuração na implantação em produção.
E se pudéssemos unificar as duas soluções em um componente de autorização centralizado, escalável e totalmente integrado ao nosso API Gateway?
A resposta para essa pergunta estava na própria documentação da AWS… Autorizador Lambda.
Centralizando o controle de acesso
Sobre autorizadores
Um autorizador é um recurso do API Gateway que usa uma função lambda para controlar o acesso aos recursos da sua API.
Quando um cliente faz uma solicitação para algum recurso da sua API, o API Gateway chama o autorizador lambda, que recebe o identificador do usuário (token ou cabeçalho da solicitação) como entrada e retorna uma política do IAM (permitido ou negado) na saída.
Criando e configurando a lambda
Nosso primeiro passo foi criar a função lambda para validar o token de acesso na API de sessão da Serasa.
A implementação foi baseada no exemplo API Gateway Authorizer do powertools.
Configuramos a concorrência provisionada para obter o máximo de execuções simultâneas, adeus throttling.
Criando o autorizador
Em seguida, criamos um autorizador do tipo lambda no API Gateway do eCred, apontando para função recém criada.
Definimos o tipo do evento (Solicitação), a chave de identificação do usuário (cabeçalho Authorization), e os segundos em que a política será armazenada em cache, para que a função lambda não precise ser invocada a cada solicitação.
Após conceder permissão para o autorizador invocar a função lambda, estávamos prontos para configurar os recursos.
Configurando os recursos
Gradativamente removemos a integração antiga (lambda-proxy e bibliotecas) e configuramos o novo autorizador.
Em cada recurso configurado, o API Gateway era implantado no estágio de homologação para ser testado.
Após ser testado com sucesso, o recurso era promovido para o estágio de produção.
Monitorando os resultados
Autorização é um fluxo crítico, toda jornada do consumidor eCred é na área logada.
Para observar o impacto do novo autorizador na experiência do produto, criamos painéis com métricas customizadas.
Dica: O powertools tem um utilitário que facilita a criação de métricas personalizadas de forma assíncrona registrando na saída padrão seguindo o Embedded Metric Format (EMF).
Conclusão
Sem bibliotecas e proxies espalhados por todo sistema, a arquitetura e experiência de desenvolvimento foi simplificada.
Com a unificação, mudanças na API de sessão agora são aplicadas em questão de segundos para todos os endpoints.
Nada disso seria possível sem a parceria da Adriane Müller, valeu Dri.
Um agradecimento especial ao Zé Henriques e Matheus Losi pela revisão do artigo.
Como é feito o controle de acesso às APIs dos produtos da sua empresa? Compartilha aí nos comentários, será um prazer conversar sobre o assunto.
