Os microsserviços devem ser usuários?

Estamos tentando determinar a melhor maneira de autorizar usuários em uma arquitetura de microsserviço, enquanto garantimos que os microsserviços tenham permissões limitadas. Nossa arquitetura usa um serviço de autorização central para lidar com a emissão de tokens JWT.

Temos os seguintes requisitos:

1. Os usuários devem ser limitados para desempenhar determinadas funções. por exemplo, um usuário deve ser capaz de criar / modificar / ler o conteúdo que ele possui.

2. Os microsserviços devem ser limitados apenas às permissões necessárias. por exemplo, um microsserviço que só precisa ler dados de outro serviço deve ser explicitamente proibido de gravar dados nesse serviço.

Como exemplo, suponha que tenhamos um sistema em que os usuários possam fazer upload de fotos para um serviço de armazenamento de imagens. Temos um serviço de marcação que marca automaticamente as fotos com um local. Os usuários podem apenas CRUD suas próprias imagens. O serviço de marcação pode ler qualquer imagem do serviço de armazenamento de imagens, mas não deve ser capaz de modificar / excluir.

Qual é uma boa maneira de conseguir isso usando os tokens JWT? Algumas soluções que discutimos são:

1. O serviço de armazenamento de imagens expõe 2 APIs, uma disponível externamente (fornecendo acesso CRUD ao usuário) e outra disponível internamente (fornecendo acesso interno somente leitura). Parece inflexível - e se outro serviço interno precisar de acesso de leitura / gravação a todas as imagens (por exemplo, um que exclua automaticamente imagens explícitas)?

2. Configuramos duas permissões no JWT do usuário, uma sendo CRUD_OwnImages, a outra sendo READ_ForAnalysis. O serviço de marcação pode ver se o usuário possui permissões READ_ForAnalysis e, se houver, fazer a solicitação apropriada. Temos outro microsserviço que verifica se o usuário possui operações CRUD_OwnImages for CRUD nas próprias imagens do usuário. Isso coloca a responsabilidade em cada microsserviço para garantir que o usuário esteja restrito às ações que ele exige. O repositório de imagens não tem como restringir cada microsserviço com essa abordagem, portanto, é potencialmente suscetível a falhas e erros.

3. Damos ao microsserviço de marcação seu próprio usuário, com READ_ForAnalysis como uma permissão. Em seguida, quando o serviço de identificação solicita imagens do armazenamento de imagens, ele recebe acesso a elas, mas é proibido modificá-las. O usuário do usuário tem apenas a permissão CRUD_OwnImages, portanto, ele pode recuperar e obter acesso apenas às imagens do frontend. Se outro serviço precisar de CRUD para todos os dados, podemos fornecer CRUD_AllData ou similar. Gostamos dessa abordagem, já que cada serviço agora é responsável por seus próprios dados (em vez de a lógica ser duplicada em vários serviços), mas e se o serviço exigir permissões de usuário e permissões de microsserviço? Podemos enviar dois tokens JWT (tanto do usuário quanto do microsserviço) com segurança? Existe uma maneira de combinar permissões com segurança e enviá-las? por exemplo

O problema é exacerbado se as informações do usuário forem necessárias mais a jusante (a 2 ou 3 microsserviços de distância). Assumimos apenas que cabe aos microsserviços individuais restringir-se às ações de que precisam e não explicitar isso?

Em geral, o maior número possível de operações deve estar vinculado a um usuário humano real. Isso força as pessoas a se autenticarem corretamente, busca uma única estratégia de autorização consistente e é uma parte importante do fornecimento de uma trilha de auditoria coesa.

E, em geral, você tem três tipos de cenários com microsserviços:

1. O usuário entra, carrega uma foto e precisa ser etiquetada. Ótimo. O serviço de foto pode apenas passar o JWT para o serviço de identificação (ou vice-versa, dependendo da direção de sua dependência) e, se o usuário não tiver direitos para executar a suboperação, você executa a ação apropriada (talvez faça o upload da foto sem uma etiqueta , talvez retorne o erro, talvez algo mais).

2. O usuário entra, carrega uma foto e precisa ser etiquetada ... mas não agora.Legal. Você lida com a foto agora como normal. Posteriormente, quando a marcação ocorrer (manipulação de eventos / mensagens, processamento de comandos no estilo CQRS, algum processamento periódico de tarefas, qualquer que seja), o serviço de marcação representará o usuário (provavelmente usando um segredo compartilhado para solicitar um JWT personalizado de autenticação) e faça a suboperação em nome do solicitante original (com todas as suas permissões e limitações). Esse método tem o problema usual de operações assíncronas, nas quais é difícil fornecer erros de volta ao usuário se as coisas não derem certo, mas se você estiver usando esse padrão para operações entre serviços, já terá resolvido isso.

3. Alguns subsistemas precisam fazer coisas fora do contexto de um usuário.Talvez você tenha algum trabalho noturno para arquivar imagens antigas. Talvez suas tags precisem ser consolidadas ... Nesse caso, você provavelmente deseja que cada um desses atores tenha seu próprio pseudo-usuário com permissões limitadas e um ID exclusivo para a trilha de auditoria.

Qual usar variará dependendo do seu cenário, suas necessidades e sua tolerância a riscos. E, é claro, esses são apenas um conjunto incompleto de generalizações gerais de AVC.

Mas, em geral, os próprios microsserviços não devem ser usuários, se possível.