Explicação do modelo de multi-tenancy do Logto

A confusão#

Podes ter ouvido falar de alguns produtos que utilizam o termo "multi-tenancy" para representar o isolamento de identidade: cada inquilino tem o seu próprio conjunto de utilizadores, papéis, permissões e dados.

Pode parecer contra-intuitivo, mas, na verdade, "multi-tenancy" indica o contrário: múltiplos inquilinos estão a partilhar recursos numa única instância. Para os utilizadores, uma identidade numa aplicação é como uma carta de condução. Por exemplo, com uma carta de condução, podes conduzir em diferentes estados (uma identidade para múltiplas organizações), em vez de teres de tirar uma nova carta de condução para cada estado.

O modelo do Logto#

No Logto, notámos esta confusão desde o início do nosso design, e esforçámo-nos para fazê-lo da maneira correta para as tuas aplicações e os teus utilizadores. Eis o nosso design:

• Um inquilino pode ser tratado como uma única instância do Logto, que tem o seu próprio conjunto de utilizadores, permissões e dados.
• Dentro de um inquilino, pode haver múltiplas organizações. Um utilizador pode ser membro de várias organizações.
• Para cada organização, segue-se o padrão de controlo de acesso baseado em papéis (RBAC) e usa-se o mesmo conjunto de papéis e permissões da organização. Este conjunto é chamado de template de organização.
• Os papéis e as permissões da organização são eficazes apenas e somente no contexto de uma organização.
  • Por exemplo, um utilizador pode ser um "administrador" (papel) numa organização, mas um "membro" (papel) noutra organização.
  • Sem o contexto de uma organização, os papéis e as permissões da organização são sem significado.
• Usa permissões da organização para controlar o acesso numa organização, em vez de usar papéis da organização.

Este modelo proporciona flexibilidade e reutilização para gerir identidades, especialmente para aplicações SaaS. Se olharmos para algumas apps SaaS populares, podemos ver que todas se encaixam neste modelo. O termo "organização" pode ser diferente em diferentes apps, como "espaço de trabalho", "equipa", etc. Mas o conceito é o mesmo.

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

• Podes criar e juntar-te a múltiplos espaços de trabalho com uma conta, em vez de te inscreveres em cada espaço de trabalho com contas diferentes.
• Para cada espaço de trabalho, o Notion define um mesmo conjunto de níveis de acesso: "Proprietário do espaço de trabalho" e "membro", enquanto podes esperar diferentes níveis de acesso para diferentes espaços de trabalho.

Assim, os utilizadores podem facilmente alternar entre espaços de trabalho sem mudar de contas ou voltar a entrar, e mantém-se o isolamento entre os espaços de trabalho. Traduzindo isto para o modelo do Logto, significa:

• O template de organização define dois papéis: "proprietário" e "membro".
• Se um utilizador se juntou a um espaço de trabalho, isso significa que o utilizador é membro de uma organização e tem o papel de "membro" na organização.
• Se um utilizador criou um espaço de trabalho, isso significa que o utilizador é membro de uma organização e tem o papel de "proprietário" na organização.

De acordo com diferentes papéis, um utilizador pode ter diferentes permissões em diferentes espaços de trabalho (organizações).

Os benefícios#

Experiência do utilizador#

Para os utilizadores, podem desfrutar da verdadeira experiência de single sign-on. Alternar entre organizações é tão fácil quanto alternar entre separadores.

Reutilização#

Uma vantagem das aplicações SaaS é que são padronizadas e escaláveis. Por exemplo, podes criar um novo espaço de trabalho no Notion com alguns cliques, e está pronto para ser utilizado.

Quando a tua aplicação está a crescer, podes querer adicionar mais papéis e permissões a cada organização. Por exemplo, um novo papel "convidado" e uma nova permissão "convidar:convidado". Pode ser um pesadelo se precisares de atualizar todas as organizações existentes uma por uma.

Com o Logto, podes atualizar o template de organização, e todas as organizações existentes serão atualizadas automaticamente.

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

No Logto, usamos o mesmo modelo de controlo de acesso (RBAC) tanto para organizações como para recursos de API. Isso significa que não precisas de aprender um novo modelo de controlo de acesso se estiveres familiarizado com o RBAC. Entretanto, eles são isolados uns dos outros, para que possas usá-los para diferentes casos de uso.

A parte mais empolgante é que podes usá-los ao mesmo tempo. Vamos expandir o exemplo do Notion:

• Para aceder a espaços de trabalho, podes usar o RBAC de organização do Logto.
• Para aceder e atualizar recursos a nível de conta (como perfil e informações de faturação), podes usar o RBAC de recurso de API do Logto.

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

As diferenças

O RBAC de organização e o RBAC de recurso de API diferem nos seguintes aspetos:

• 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 numa organização, enquanto o RBAC de recurso de API é usado para controlar o acesso a recursos de API.
• Um utilizador pode ter papéis diferentes em organizações diferentes, enquanto os papéis para recurso de API são universais no inquilino.
• Papéis e permissões são isolados para esses dois tipos de RBAC.

Notas finais#

Construir uma aplicação SaaS é difícil, e esperamos que o Logto possa ajudar-te a focar-te no teu core business. Não hesites em dar-nos feedback se tiveres alguma dúvida ou sugestão.