Autenticação e autorização em arquitetura de microsserviços
(microservices.io)Esta série aborda como implementar autenticação (Authentication) e autorização (Authorization) em arquitetura de microsserviços.
Este artigo explica a visão geral e as diferenças em relação a uma aplicação única (monolítica).
Aplicação de exemplo: RealGuard.io
A RealGuard.io é uma plataforma de sistemas de segurança comercial que gerencia o controle de equipamentos de segurança e alarmes.
Os usuários pertencem a revendedores, empresas clientes e provedores de monitoramento, e cada grupo tem permissões de acesso diferentes.
Autenticação e autorização em arquitetura monolítica
Uma estrutura monolítica é composta por uma única aplicação e um único banco de dados, e a autenticação é implementada com token de sessão.
A autorização é realizada com a seguinte estrutura:
isAllowed(user, operation, resource)
Exemplo:
isAllowed(user, "disarm", SecuritySystem(ID))
Quatro modelos de autorização
- RBAC: controle de acesso baseado em papéis – a permissão é determinada pelos papéis atribuídos ao usuário
- ReBAC: controle de acesso baseado em relacionamentos – o acesso é determinado pela relação entre usuário e recurso
- ABAC: controle de acesso baseado em atributos – a decisão é baseada em atributos do usuário, do recurso e do ambiente
- Modelo híbrido: permite implementar políticas mais complexas combinando os três modelos acima
Exemplo de autorização e permissões por papel
| Operation | Required Role |
|---|---|
| getAlarmSystem() | SecuritySystemViewer |
| armSystem() | SecuritySystemArmer |
| disarmSystem() | SecuritySystemDisarmer |
| cancelSystem() | SecuritySystemAlarmCanceller |
Além de papéis específicos, também podem ser aplicadas condições adicionais, como restrições de horário de trabalho (ABAC) ou inclusão em uma lista de notificações.
Onde validar a autorização
- Infraestrutura de rede: é possível fazer verificações simples de permissão em service mesh, ingress controller etc.
- Handlers de API REST: tratam autorização coarse-grained no nível da requisição
- Lógica de domínio: trata autorização baseada em condições complexas
- Camada de acesso ao banco de dados: faz filtragem de autorização dentro do SQL (efetiva para processamento em grande volume)
Autorização na UI
A UI não pode impor a autorização, mas pode otimizar a UX exibindo ou desativando botões/funcionalidades de acordo com as permissões do usuário.
Autenticação em arquitetura de microsserviços
O BFF (Backend For Frontend) é responsável pelo login e pelo gerenciamento de sessão.
Como cada microsserviço é executado de forma independente, ele não pode acessar diretamente as informações do usuário na sessão, então é necessário transmitir essas informações por meio de tokens, como JWT.
Autorização em arquitetura de microsserviços
As requisições são encaminhadas na ordem BFF → SecurityService, e a validação da autorização pode acontecer em três pontos:
- BFF: pode fazer autorização no nível da requisição com base nas informações da sessão, conforme rota e método
- Inter-service Network: o service mesh executa parte da autorização com base em JWT
- Dentro de cada serviço: a autorização é feita na lógica de domínio e na camada de acesso ao banco de dados
Dificuldades da autorização distribuída
Como cada serviço não possui em seu próprio banco de dados todas as informações de que precisa, pode ser necessário chamar APIs de outros serviços para autorizar.
Há também a abordagem de tentar resolver isso com JWT, mas o tamanho do token e o custo de validação se tornam problemas.
Resumo
- Autenticação é a verificação da identidade do usuário; autorização é a decisão sobre permissões
- O padrão
isAllowed(user, operation, resource)é o núcleo da autorização - A implementação combina os três modelos de autorização: RBAC, ReBAC e ABAC
- Em monólitos, a autorização é mais fácil com acesso a um único banco de dados
- Em microsserviços, a implementação é mais complexa porque os dados necessários para autorizar estão distribuídos
Ainda não há comentários.