Explicación del modelo de multi-tenancy de Logto

La confusión#

Es posible que hayas oído hablar de algunos productos que utilizan el término "multi-tenancy" para representar el aislamiento de identidad: cada inquilino tiene su propio conjunto de usuarios, roles, permisos y datos.

Puede ser contraintuitivo, pero de hecho, "multi-tenancy" indica lo contrario: múltiples inquilinos comparten recursos en una sola instancia. Para los usuarios, una identidad en una aplicación es como una licencia de conducir. Por ejemplo, con una licencia de conducir, puedes conducir en diferentes estados (una identidad para múltiples organizaciones), en lugar de solicitar una nueva licencia de conducir para cada estado.

El modelo de Logto#

En Logto, nos dimos cuenta de esta confusión al principio de nuestro diseño, y nos esforzamos en hacerlo bien para tus aplicaciones y tus usuarios. Aquí está nuestro diseño:

• Un inquilino se puede tratar como una única instancia de Logto, que tiene su propio conjunto de usuarios, permisos y datos.
• Dentro de un inquilino, puede haber múltiples organizaciones. Un usuario puede ser miembro de múltiples organizaciones.
• Para cada organización, sigue el patrón de control de acceso basado en roles (RBAC) y utiliza el mismo conjunto de roles y permisos de la organización. Este conjunto se llama plantilla de organización.
• Los roles y permisos de la organización son efectivos solo en el contexto de una organización.
  • Por ejemplo, un usuario puede ser un "administrador" (rol) en una organización, pero un "miembro" (rol) en otra organización.
  • Sin el contexto de una organización, los roles y permisos de la organización son irrelevantes.
• Usa los permisos de la organización para controlar el acceso en una organización, en lugar de usar los roles de la organización.

Este modelo proporciona la flexibilidad y reutilización para gestionar identidades, especialmente para aplicaciones SaaS. Si observamos algunas aplicaciones SaaS populares, podemos ver que todas pueden encajar en este modelo. El término "organización" puede ser diferente en cada aplicación, como "espacio de trabajo", "equipo", etc. Pero el concepto es el mismo.

Por ejemplo, en Notion (una herramienta de colaboración popular):

• Puedes crear y unirte a múltiples espacios de trabajo con una sola cuenta, en lugar de registrarte para cada espacio de trabajo con diferentes cuentas.
• Para cada espacio de trabajo, Notion define un mismo conjunto de niveles de acceso: "propietario del espacio de trabajo" y "miembro", mientras que podrías esperar diferentes niveles de acceso para diferentes espacios de trabajo.

Por lo tanto, los usuarios pueden cambiar entre espacios de trabajo fácilmente sin cambiar de cuenta ni volver a iniciar sesión, y esto mantiene el aislamiento entre los espacios de trabajo. Traduciendo esto al modelo de Logto, significa:

• La plantilla de organización define dos roles: "propietario" y "miembro".
• Si un usuario se unió a un espacio de trabajo, significa que el usuario es miembro de una organización y tiene el rol de "miembro" en la organización.
• Si un usuario creó un espacio de trabajo, significa que el usuario es miembro de una organización y tiene el rol de "propietario" en la organización.

De acuerdo con los diferentes roles, un usuario puede tener diferentes permisos en diferentes espacios de trabajo (organizaciones).

Los beneficios#

Experiencia del usuario#

Para los usuarios, pueden disfrutar de una verdadera experiencia de inicio de sesión único. Cambiar entre organizaciones es tan fácil como cambiar entre pestañas.

Reutilización#

Una ventaja de las aplicaciones SaaS es que son estandarizadas y escalables. Por ejemplo, puedes crear un nuevo espacio de trabajo en Notion con unos pocos clics, y está listo para usar.

Cuando tu aplicación crece, puedes querer añadir más roles y permisos a cada organización. Por ejemplo, un nuevo rol "invitado" y un nuevo permiso "invitar:invitado". Puede ser una pesadilla si necesitas actualizar todas las organizaciones existentes una por una.

Con Logto, puedes actualizar la plantilla de organización, y todas las organizaciones existentes se actualizarán automáticamente.

Un modelo de control de acceso, múltiples casos de uso#

En Logto, utilizamos el mismo modelo de control de acceso (RBAC) tanto para las organizaciones como para los recursos de la API. Esto significa que no necesitas aprender un nuevo modelo de control de acceso si estás familiarizado con RBAC. Mientras tanto, están aislados entre sí, por lo que puedes utilizarlos para diferentes casos de uso.

La parte más emocionante es que puedes utilizarlos al mismo tiempo. Extendamos el ejemplo de Notion:

• Para acceder a los espacios de trabajo, puedes usar el RBAC de la organización de Logto.
• Para acceder y actualizar los recursos a nivel de cuenta (como el perfil y la información de facturación), puedes usar el RBAC de recurso de la API de Logto.

La mayoría de los SDKs de Logto soportan ambos tipos de RBAC.

Las diferencias

El RBAC de organización y el RBAC de recurso de la API son diferentes en los siguientes aspectos:

• El RBAC de organización requiere el contexto de una organización, mientras que el RBAC de recurso de la API no.
• El RBAC de organización se usa para controlar el acceso en una organización, mientras que el RBAC de recurso de la API se utiliza para controlar el acceso a los recursos de la API.
• Un usuario puede tener diferentes roles de organización en diferentes organizaciones, mientras que los roles para los recursos de la API son universales en el inquilino.
• Los roles y permisos están aislados para estos dos tipos de RBAC.

Notas finales#

Construir una aplicación SaaS es difícil, y esperamos que Logto pueda ayudarte a centrarte en tu negocio principal. No dudes en darnos tu opinión si tienes alguna pregunta o sugerencia.