Padrões e Práticas para tratar Autorização em Microsserviços

Autorização, em qualquer aplicação não é processo simples. Quando estamos implementando Microsserviços, o desafio pode ser um pouco maior.

Neste post, compartilho uma nova perspectiva, proposta pelos autores do IdentityServer4 para o processo de autorização, fazendo devidas considerações para Microsserviços.

Se tiver interesse em entender mais sobre microsserviços, recomendo que acesse o Guia de Conteúdo para Microsserviços deste site.

Aliás, se estiver realmente interessado no tema, recomendo que assita o vídeo abaixo. Trata-se de uma palestra do Broke Alen e do Dominick Baier apresentando o projeto PolicyServer.

https://vimeo.com/254635640

Identity != Permissions

Frequentemente, tenho visto Autorização ser implementada a partir de claims fornecidos pelo serviço de autenticação. Essa abordagem, entretanto, pode gerar um conjunto enorme de problemas (afinal, o acoplamento é muito forte).

A ideia proposta, de forma simplificada, é de que deveria ser responsabilidade do serviço de autenticação fornecer apenas dados relacionados a identidade. Esses dados, geralmente, sofrem poucas modificações ao longo do tempo.

Permissões (Autorização), diferentemente da identidade, podem ser redefinidas com muito mais frequência. Seja pela mudança das políticas organizacionais, seja pela adição de novas funcionalidades aos Microsserviços.

O servidor de identidade é crítico demais, em qualquer implementação de microsserviços, para ter dados modificados com frequência.

Uma abordagem mais adequadas para tratamento de autorização, estou convencido, seria que esta fosse uma responsabilidade de cada microsserviço. Identidade é universal para o sistema, permissões são específicas para cada microsserviço.

Identities + Permissions == Authorization

De Roles Globais para Roles do Contexto

Roles definidas no servidor de identidade, geralmente, são específicas demais para serem utilizadas de forma eficiente em um microsserviços. A tentativa de levar roles dos microsserviços para o servidor de identidade, ou o contrário, levam a acoplamento demasiado grande.

Geralmente, em microsserviços, temos Roles adaptadas mais adequadas ao contexto. O ideal, é que exista a possibilidade de mapear roles da identidade para Roles do microsserviço.

Vejamos esse exemplo extraído de uma demonstração do PolicyServer.

{
  "Policy": {
    "roles": [
      {
        "name": "doctor",
        "subjects": [ "1", "2" ],
        "identityRoles": [ "surgeon" ]
      },
      {
        "name": "nurse",
        "subjects": [ "11", "12" ],
        "identityRoles": [ "RN" ]
      },
      {
        "name": "patient",
        "identityRoles": [ "customer" ]
      }
    ],
...

No exemplo, vemos um “de-para” de roles do servidor de identidade para roles específicas de um microsserviço.

Perceba:

  • há um nítido ajuste para a linguagem ubíqua do contexto delimitado, indicado, por exemplo, que um “customer” no contexto do microsserviço deverá ser interpretado como “patient“;
  • ocorre uma  normalização das Roles apontando que todo cirurgião (surgeon) é, na prática, um médico (doctor) – para o microsserviço, a especialidade do médico pode ser irrelevante;
  • é possível fazer a inclusão de usuários (identidades) específicos para determinadas Roles apenas no microsserviço.

Autorização por permissões, não por Roles

Outra recomendação interessante é a de pensar autorização pelo controle de permissões, não de Roles. Vejamos o exemplo proposto na demonstração do PolicyServer.

  "permissions": [
      {
        "name": "SeePatients",
        "roles": [ "doctor", "nurse" ]
      },
      {
        "name": "PerformSurgery",
        "roles": [ "doctor" ]
      },
      {
        "name": "PrescribeMedication",
        "roles": [ "doctor", "nurse" ]
      },
      {
        "name": "RequestPainMedication",
        "roles": [ "patient" ]
      }
    ]
  }
}

Aqui, temos uma relação das operações que iremos controlar, relacionando-as com as roles especificas do microsserviço.

Repare que há permissões que estão habilitadas para mais de uma Role.

Resumindo

Tenha um servidor de identidade, com dados globais e que sofrem poucas modificações ao longo do tempo. Feito isso, implemente regras de autorização de forma independente em cada microsserviço (considere dar uma olhada no PolicyServer – parece bastante promissor).

Capa:Andrew Haimerl

Compartilhe este insight:

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

O ano era 2001 ou 2002. Não lembro ao certo. Eu era um jovem programador, pai recente, tentando “encontrar meu...
Este post foi originalmente publicado em 2015 (infelizmente, a postagem original não está mais disponível) Nesse post vamos implementar, passo-a-passo,...
Our goal is to fill a two-dimensional array with 1’s. using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Running; namespace ToArrays { public class Program...
As professionals, we should focus on developing great technical solutions. But, these solutions need to solve real problems. At the...
The following works as expected when building in Debug – the execution is done after three seconds. But, for some...
Aqui, um registro da apresentação que realizei na abertura do IoT Weekend. O que você acha do que foi dito?

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano anual do Clube de Estudos:

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano mensal do Clube de Estudos:

Mentoria em
Arquitetura de Software
com ênfase em IA

Aprenda a coordenar equipes de desenvolvimento, aplicar padrões e técnicas de arquitetura e aumentar sua produtividade criando sistemas inovadores com o suporte da IA.

× Precisa de ajuda?