Propósito

O objetivo desse Spike é analisar as melhores práticas de Autenticação e Autorização em integração via AMQP, definindo ao final como serão realizados na integração via protocolo Transactions.

Desenvolvimento

Foram realizadas pesquisas sobre práticas de mercado e reuniões de Brainstorm com representantes da linha Protheus, Datasul, TNF (RAC) e RM. 

Abaixo são listadas as duas principais abordagens discutidas, sendo a primeira considerada a ideal e a segunda a viável para o momento atual. Estas características serão melhor explicadas nos respectivos itens.

Autenticação global e autorização por serviço

Este modelo se baseia na autenticação via OAuth2 e o tráfego do Token JWT entre os sistemas, que ficam assim responsáveis pela validação do mesmo e pela autorização na devida rotina. A implementação deste modelo tem como premissa a utilização de um Identity Server entre os sistemas integrados, assim havendo equivalência entre os usuários dos aplicativos. 

Apesar de ser considerada a melhor abordagem, este modelo não será implementado no primeiro momento pois as Frameworks das principais linhas TOTVS não estão preparadas para autenticação via OAuth2 e/ou Token JTW em integração entre elas. Deve-se acompanhar a evolução das linhas e assim que haja viabilidade técnica proceder com a implementação desta abordagem.

Pontos de atenção:

• O RabbitMQ, ou outro Broker AMQP utilizado, é responsável somente por trafegar o Token JWT entre os sistemas, não sendo necessário realizar a validação do Token ou autorização por vhost, exchange ou queue.
• O aplicativo de destino deve identificar e preencher no contexto de execução o usuário relacionado ao Token JWT.
• A autorização é de responsabilidade do sistema de destino.
  
  

Autenticação local no RabbitMQ 

Esta solução considera que todos os sistemas envolvidos, inclusive o RabbitMQ, possuem autenticação própria e sem equivalência de usuários entre eles. Assim sendo, deve-se realizar a criação de usuários e definir o acesso a vhost e filas de cada um deles internamente ao RabbitMQ.

Devido à simplicidade de implementação e segurança equivalente aos modelos utilizados via Soap ou Rest, esta será a solução abordada até a viabilidade da implementação da solução ideal, listada no tópico anterior.

Cada sistema integrado deve possuir a parametrização de usuário e senha para autenticação do RabbitMQ no momento do envio de mensagens e outra parametrização que defina o usuário a ser utilizado no processamento de mensagens recebidas pelos Consumers.

Pontos de atenção:

• O RabbitMQ deve ser parametrizado, realizando a criação dos usuários a serem utilizados e o permissionamento dos mesmos para vhost, exchange ou queue.
• Os aplicativos integrados devem possuir parametrização do usuário e senha utilizados para autenticação no RabbitMQ.
• Os consumers devem obter o usuário de contexto para processamento das mensagens a partir de parametrização própria.
  • O Protheus atualmente utiliza o usuário que realizou o agendamento do Schedule, enquanto o RM utilizará um parâmetro das configurações gerais do EAI.

Autenticação de Microserviços

Após reuniões de alinhamento e brainstorm com participantes de praticamente todas as linhas, identificamos diversas formas de autenticação e autorização e chegamos ao consenso de que não é aconselhável tomarmos qualquer tipo de definição neste momento. Para ter assertividade nesta definição a arquitetura de microserviços da TOTVS precisa estar mais madura e ter outras definições arquiteturais que precedem esta. 

Referências bibliográficas

• Microservices Authentication & Authorization Best Practice
• Microservices Authentication and Authorization Solutions
• Access Control (Authentication, Authorisation) in RabbitMQ
• Plugin Rabbitmq para autenticação via OAuth2
• StackOverflow: Microservice Authentication Strategy