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
