O modelo de multi-tenancy do Logto explicado

A confusão#

Você pode ter ouvido falar de alguns produtos que utilizam o termo "multi-tenancy" para representar a isolação de identidade: cada inquilino tem seu próprio conjunto de usuários, funções, permissões e dados.

Pode parecer contraintuitivo, mas na verdade, "multi-tenancy" indica o contrário: múltiplos inquilinos compartilham recursos em uma única instância. Para os usuários, uma identidade em um aplicativo é como uma carteira de motorista. Por exemplo, com uma carteira de motorista, você pode dirigir em diferentes estados (uma identidade para múltiplas organizações), em vez de solicitar uma nova carteira de motorista para cada estado.

O modelo do Logto#

No Logto, percebemos essa confusão no início do nosso design, e nos esforçamos para acertar com seus aplicativos e seus usuários. Aqui está o nosso design:

• Um inquilino pode ser tratado como uma única instância do Logto, que possui seu próprio conjunto de usuários, permissões e dados.
• Dentro de um inquilino, pode haver várias organizações. Um usuário pode ser membro de várias organizações.
• Para cada organização, segue-se o padrão de controle de acesso baseado em funções (RBAC) e usa-se o mesmo conjunto de funções e permissões da organização. Esse conjunto é chamado de template da organização.
• As funções e permissões da organização são eficazes somente no contexto de uma organização.
  • Por exemplo, um usuário pode ser um "admin" (função) em uma organização, mas um "membro" (função) em outra organização.
  • Sem o contexto de uma organização, as funções e permissões da organização são irrelevantes.
• Use as permissões da organização para controlar o acesso em uma organização, em vez de usar as funções da organização.

Esse modelo fornece flexibilidade e reutilização para a gestão de identidades, especialmente para aplicativos SaaS. Se olharmos para alguns aplicativos SaaS populares, podemos ver que todos se encaixam nesse modelo. O termo "organização" pode variar em diferentes aplicativos, como "workspace", "time", etc. Mas o conceito é o mesmo.

Por exemplo, no Notion (uma ferramenta popular de colaboração):

• Você pode criar e entrar em múltiplos workspaces com uma única conta, em vez de se inscrever para cada workspace com contas diferentes.
• Para cada workspace, o Notion define um mesmo conjunto de níveis de acesso: "Proprietário do workspace" e "membro", enquanto você pode esperar diferentes níveis de acesso para diferentes workspaces.

Assim, os usuários podem facilmente alternar entre workspaces sem trocar de contas ou fazer login novamente, e mantém a isolação entre workspaces. Traduzindo isso para o modelo do Logto, significa:

• O template da organização define duas funções: "proprietário" e "membro".
• Se um usuário entrou em um workspace, significa que o usuário é um membro de uma organização, e ele tem a função de "membro" na organização.
• Se um usuário criou um workspace, significa que o usuário é um membro de uma organização, e ele tem a função de "proprietário" na organização.

De acordo com diferentes funções, um usuário pode ter diferentes permissões em diferentes workspaces (organizações).

Os benefícios#

Experiência do usuário#

Para os usuários, eles podem desfrutar da verdadeira experiência de login único. Alternar entre organizações é tão fácil quanto alternar entre abas.

Reutilização#

Uma vantagem dos aplicativos SaaS é que eles são padronizados e escaláveis. Por exemplo, você pode criar um novo workspace no Notion com alguns cliques, e ele estará pronto para usar.

Quando seu aplicativo está crescendo, você pode querer adicionar mais funções e permissões para cada organização. Por exemplo, uma nova função "convidado" e uma nova permissão "convidar:convidado". Pode ser um pesadelo se você precisar atualizar todas as organizações existentes uma por uma.

Com o Logto, você pode atualizar o template da organização, e todas as organizações existentes serão atualizadas automaticamente.

Um modelo de controle de acesso, múltiplos casos de uso#

No Logto, usamos o mesmo modelo de controle de acesso (RBAC) para ambas as organizações e recursos de API. Isso significa que você não precisa aprender um novo modelo de controle de acesso se já estiver familiarizado com RBAC. Enquanto isso, eles são isolados entre si, então você pode utilizá-los para diferentes casos de uso.

A parte mais empolgante é que você pode usá-los ao mesmo tempo. Vamos estender o exemplo do Notion:

• Para acessar workspaces, você pode usar o RBAC de organização do Logto.
• Para acessar e atualizar recursos em nível de conta (como perfil e informações de cobrança), você pode usar o RBAC de recurso de API do Logto.

A maioria dos SDKs do Logto suporta ambos os tipos de RBAC.

As diferenças

RBAC de organização e RBAC de recurso de API são diferentes nos seguintes aspectos:

• O RBAC de organização requer o contexto de uma organização, enquanto o RBAC de recurso de API não.
• O RBAC de organização é usado para controlar o acesso em uma organização, enquanto o RBAC de recurso de API é usado para controlar o acesso a recursos de API.
• Um usuário pode ter diferentes funções de organização em diferentes organizações, enquanto as funções para recurso de API são universais no inquilino.
• Funções e permissões são isoladas para esses dois tipos de RBAC.

Notas finais#

Construir um aplicativo SaaS é difícil, e esperamos que o Logto possa ajudá-lo a focar no seu core business. Não hesite em nos dar feedback se você tiver alguma dúvida ou sugestão.