Português (Brasil)
  • saas
  • colaboração
  • organizações
  • rbac
  • multi-tenancy

Nos bastidores: Como implementamos a colaboração de usuários em um aplicativo multi-tenant

Práticas e insights sobre como implementar um recurso de convite e gerenciamento de acesso a funções, como a colaboração no Logto Cloud em uma aplicação multi-tenant.

Charles
Charles
Developer

Contexto

Na semana passada, nós introduzimos o recurso de colaboração no Logto Cloud. Se você perdeu, confira! Agora, você pode convidar colegas e colaboradores para seus locatários Logto existentes, colaborando juntos na manutenção do sistema de identidade para suas aplicações.

Nesta versão, adicionamos dois papéis a cada locatário Logto:

  • Admin: Acesso total ao locatário, incluindo o gerenciamento de recursos relacionados à identidade, convite e gerenciamento de outros membros, manipulação de cobrança e visualização do histórico de cobranças.
  • Colaborador: Pode gerenciar recursos relacionados à identidade, mas não tem acesso a outros recursos de administrador.

Consistente com nosso compromisso de usar nossas próprias ferramentas, utilizamos nosso recurso RBAC (Controle de Acesso Baseado em Função) e Organizações para construir a colaboração de usuários. Se você é novo no RBAC, confira nosso post anterior para começar.

Neste post do blog, vamos dar uma olhada no que foi necessário para implementar este recurso e como essas práticas podem beneficiar você se estiver desenvolvendo aplicativos multi-organizacionais.

A colaboração do Logto Cloud é construída com Logto Organizações

Cada locatário do Logto Cloud funciona como uma organização independente em nosso sistema, impulsionada pelo nosso próprio recurso de Organizações. Para introduzir os papéis de administrador de locatários e colaborador, criamos dois papéis organizacionais no modelo de organização, cada um atribuído a um conjunto específico de permissões da organização.

Papéis da organização
Escopos da organização

Lidar com convites com a API de Gerenciamento do Logto

Fornecemos um conjunto de APIs de Gerenciamento relacionadas a convites no recurso de organizações. Com essas APIs, você pode, por exemplo:

  • POST /api/organization-invitations criar e enviar um convite de organização para um endereço de e-mail
  • GET /api/organization-invitations & GET /api/organization-invitations/{id} obter seus convites
  • PUT /api/organization-invitations/{id}/status aceitar ou rejeitar o convite atualizando o status do convite

Para mais detalhes, consulte a documentação completa da API.

Conecte-se ao seu conector de e-mail

Como os convites são enviados por e-mail, certifique-se de que o seu conector de e-mail esteja configurado corretamente. Nesta versão, introduzimos um novo tipo de uso de modelo de e-mail, OrganizationInvitation, permitindo a personalização do modelo de e-mail de convite.

Amostra de e-mail de convite

Este modelo de e-mail aceitará por padrão uma variável {{link}}, que é o link para a página de entrada do Console Logto, onde os usuários podem aceitar o convite e juntar-se a um locatário do Logto. Uma das páginas de entrada no Logto Cloud parece com a captura de tela abaixo:

Página de entrada de convite

Consulte a documentação da API para mais detalhes sobre o envio do e-mail de convite através da API de Gerenciamento.

Use RBAC para gerenciar permissões de usuários

Com as configurações acima, podemos enviar convites por e-mail, e os convidados podem juntar-se à organização com o papel atribuído.

Usuários com diferentes papéis na organização terão diferentes escopos (permissões) em seus tokens de acesso. Portanto, tanto o aplicativo cliente (Console Logto) quanto nossos serviços de backend devem verificar esses escopos para determinar os recursos visíveis e as ações permitidas.

Certo, até agora tudo parece conectado, o que mais estamos esquecendo?

Lidar com atualizações de escopos nos tokens de acesso

Gerenciar atualizações de escopos nos tokens de acesso envolve:

  • Revogar escopos existentes: Por exemplo, rebaixar um administrador para um colaborador não administrador automaticamente reduz os escopos no novo token de acesso obtido com o token de atualização existente.
  • Conceder novos escopos: Por outro lado, promover um usuário a administrador exige o acionamento de um novo login ou reconsentimento para refletir a mudança nos tokens de acesso do usuário.

No Logto Cloud, o Console verifica ativamente os escopos dos usuários usando solicitações SWR, e nós concedemos o reconsentimento automaticamente sempre que um usuário é promovido a administrador.

Se você estiver implementando um recurso semelhante com RBAC, precisará de um mecanismo (por exemplo, WebSocket ou eventos push do servidor) para notificar seu aplicativo sobre as atualizações de escopos, permitindo reconsentimento ou emissão de novos tokens de acesso conforme necessário. O Logto também fornecerá mais webhooks para auxiliar nisso em atualizações futuras.

Resumindo

Os recursos de multi-tenancy e colaboração do Logto Cloud aproveitam nosso recurso de Organizações. Se você está desenvolvendo um aplicativo multi-tenant semelhante, considere utilizar este recurso com abordagens semelhantes.

Espero que este post do blog seja útil. Para perguntas ou discussões, sinta-se à vontade para se juntar ao nosso canal do Discord.