La guía definitiva para configurar la autenticación y autorización multitenant
Crear una aplicación multitenant puede ser complejo. Este artículo recopila todas nuestras publicaciones pasadas sobre estrategias multitenant y de organización. Esperamos que te ayude a ahorrar tiempo y empezar fácilmente.
Product & Design
Construir una aplicación multitenant puede ser desafiante, con muchos aspectos a considerar. Este artículo compila todas nuestras publicaciones anteriores en el blog sobre la comprensión de prácticas multitenant y de organización. Para un comienzo rápido y para ahorrar tiempo, solo revisa este artículo, ¡incluye todo lo que necesitas!
Las pautas generales están delineadas en los siguientes pasos:
- Comprender la arquitectura multitenant
- Mapear los casos de uso de tu aplicación multitenant
- Lograr el aislamiento de inquilinos
- Definir cómo deseas gestionar las identidades
- Elegir los modelos de autorización apropiados
¿Qué es la arquitectura multitenant?
La multi-tenant de software es una arquitectura de software en la que una sola instancia de software se ejecuta en un servidor y sirve a múltiples inquilinos. Los sistemas diseñados de tal manera son "compartidos" (en lugar de "dedicados" o "aislados").
Un inquilino es un grupo de usuarios que comparte un acceso común con privilegios específicos a la instancia de software.
Una de las mentalidades clave de multi-tenant es “compartido”. En la definición más amplia de multi-tenant, ser una aplicación multitenant no implica que cada componente de una solución sea compartido. Más bien, implica que al menos algunos componentes de una solución se reutilizan entre múltiples inquilinos. Comprender este término de manera amplia puede ayudarte mejor a empatizar con las necesidades de tu cliente y de dónde provienen.
Una vez que comprendes la arquitectura multitenant, el siguiente paso es aplicar tu aplicación a escenarios del mundo real, enfocándose en necesidades específicas de producto y negocio.
¿Cuáles son los casos de uso para aplicaciones multitenant?
Multi-tenant en SaaS
Las aplicaciones multitenant a menudo encuentran su lugar en soluciones de negocio a negocio (B2B) como herramientas de productividad, software de colaboración y otros productos de software como servicio (SaaS). En este contexto, cada "inquilino" típicamente representa a un cliente de negocio, que podría tener múltiples usuarios (sus empleados). Además, un cliente de negocio podría tener múltiples inquilinos para representar organizaciones distintas o divisiones de negocio.
Multi-tenant en casos de uso genéricos B2B
Las aplicaciones B2B van más allá de los productos SaaS y a menudo implican el uso de aplicaciones multitenant. En contextos B2B, estas aplicaciones sirven como una plataforma común para que varios equipos, clientes de negocio y empresas asociadas accedan a tus aplicaciones.
Por ejemplo, considera una compañía de viajes compartidos que proporciona tanto aplicaciones B2C como B2B. Las aplicaciones B2B sirven a múltiples clientes de negocio, y emplear una arquitectura multitenant puede ayudar en la gestión de sus empleados y recursos. Para ilustrar, si la compañía desea mantener un sistema de identidad de usuario unificado, puede diseñar una arquitectura como el siguiente ejemplo:
Sarah tiene tanto una identidad personal como una de negocio. Ella utiliza el servicio de viajes compartidos como pasajera y también trabaja como conductora en su tiempo libre. En su rol profesional, también administra su negocio y utiliza esta identidad empresarial para ser socia con Empresa 1.
¿Por qué deberías emplear la multi-tenant en productos SaaS?
Escalando con multi-tenant
Para las empresas, la multi-tenant es la clave para cumplir efectivamente con sus requisitos de disponibilidad, gestión de recursos, gestión de costos y seguridad de datos. A nivel técnico, adoptar un enfoque multitenant agiliza tus procesos de desarrollo, minimiza los desafíos técnicos y promueve una expansión fluida.
Creando una experiencia unificada
Al examinar las raíces de los productos SaaS, es similar a un edificio que alberga varios apartamentos. Todos los inquilinos comparten servicios comunes como agua, electricidad y gas, pero mantienen un control independiente sobre la gestión de su propio espacio y recursos. Este enfoque simplifica la gestión de propiedades.
Asegurando la seguridad a través de la aislamiento de inquilinos
En una arquitectura multitenant, se introduce el término "inquilino" para crear límites que separen y aseguren los recursos y datos de diferentes inquilinos dentro de una instancia compartida. Esto garantiza que los datos y las operaciones de cada inquilino permanezcan distintas y seguras, incluso si están utilizando los mismos recursos subyacentes.
¿Por qué deberías lograr el aislamiento de inquilinos?
Al discutir aplicaciones multitenant, siempre es necesario lograr el aislamiento de inquilinos. Esto significa mantener los datos y recursos de diferentes inquilinos separados y seguros dentro de un sistema compartido (por ejemplo, una infraestructura en la nube o una aplicación multitenant). Esto previene cualquier intento no autorizado de acceder a los recursos de otro inquilino.
Mientras que la explicación puede parecer abstracta, usaremos ejemplos y detalles clave para explicar más la mentalidad de aislamiento y la mejor práctica para lograr el aislamiento de inquilinos.
El aislamiento de inquilinos no va en contra de la mentalidad "compartida" de multi-tenant
Eso se debe a que el aislamiento de inquilinos no es necesariamente una construcción a nivel de recursos de infraestructura. En el ámbito de la multi-tenant y el aislamiento, algunos ven el aislamiento como una división estricta entre los recursos de infraestructura reales. Esto generalmente lleva a un modelo donde cada inquilino tiene bases de datos separadas, instancias de computación, cuentas o nubes privadas. En escenarios de recursos compartidos, como aplicaciones multitenant, la forma de lograr aislamiento puede ser una construcción lógica.
El aislamiento de inquilinos se centra exclusivamente en usar el contexto de "inquilino" para limitar el acceso a los recursos. Evalúa el contexto del inquilino actual y utiliza ese contexto para determinar qué recursos son accesibles para ese inquilino.
Autenticación y autorización no son iguales a “aislamiento”
Usar la autenticación y la autorización para controlar el acceso a tus entornos SaaS es importante, pero no es suficiente para un aislamiento completo. Estos mecanismos son solo una parte del rompecabezas de seguridad.
A menudo, la gente pregunta, ¿puedo usar soluciones generales de autorización y control de acceso basado en roles para lograr el aislamiento de inquilinos?
Aquí está la cosa, puedes construir una aplicación multitenant pero no puedes decir que has logrado y empleado estrategias de aislamiento de inquilinos como una mejor práctica. Generalmente no lo recomendamos porque
Para ilustrar, considera una situación donde has configurado la autenticación y la autorización para tu sistema SaaS. Cuando los usuarios inician sesión, reciben un token que contiene información sobre su rol, dictando lo que pueden hacer en la aplicación. Este enfoque mejora la seguridad pero no asegura el aislamiento.
Usa "organización" para representar al inquilino del producto SaaS, para lograr el aislamiento de inquilinos
Confiar únicamente en la autenticación y la autorización no impedirá a un usuario con el rol adecuado acceder a los recursos de otro inquilino. Por lo tanto, necesitamos incorporar un contexto de "inquilino", como un ID de inquilino, para restringir el acceso a los recursos.
Aquí es donde entra en juego el aislamiento de inquilinos. Utiliza identificadores específicos de inquilinos para establecer límites, como muros, puertas y cerraduras, asegurando una clara separación entre los inquilinos.
Gestión de identidades en aplicaciones multi-tenant
Hablamos sobre el aislamiento de inquilinos, pero ¿qué pasa con las identidades? ¿Cómo decides si tus identidades deberían estar "aisladas" o no?
A menudo hay confusión acerca del concepto de "aislamiento de identidad." Podría referirse a situaciones donde un usuario del mundo real tiene dos identidades en la comprensión general de la gente.
- Ambas identidades pueden existir dentro de un único sistema de identidad. Por ejemplo, Sarah podría tener un correo electrónico personal registrado junto con un correo electrónico corporativo conectado a través de inicio de sesión único (SSO).
- Los usuarios mantienen dos identidades distintas dentro de sistemas de identidad separados, que representan productos completamente separados. Estos productos no están relacionados entre sí.
A veces, estos escenarios se refieren como "identidad aislada." Sin embargo, esta etiqueta podría no ayudar a tomar una decisión.
En lugar de determinar si necesitas "aislamiento de identidad," considera
Esta respuesta puede guiar el diseño de tu sistema. Para una respuesta breve con respecto a una aplicación multitenant,
En aplicaciones multitenant, las identidades, a diferencia de los recursos y datos específicos de inquilinos, se comparten entre múltiples inquilinos. Imagínate como el administrador del edificio; no querrías mantener dos hojas de nombres separadas para gestionar las identidades de tus inquilinos.
Al apuntar al aislamiento de inquilinos, podrías haber observado el énfasis recurrente en el término "organización," a menudo considerado una mejor práctica para construir aplicaciones multitenant.
Al emplear la noción de "organización," puedes lograr el aislamiento de inquilinos en tu aplicación multitenant mientras mantienes un sistema de identidad unificado.
Cómo elegir y diseñar el modelo de autorización apropiado
Al seleccionar el modelo de autorización correcto, considera estas preguntas:
- ¿Estás desarrollando un producto B2C, B2B, o una combinación de ambos tipos?
- ¿Tu aplicación tiene una arquitectura multitenant?
- ¿Existe la necesidad de un cierto nivel de aislamiento en tu aplicación, según lo determinado por la unidad de negocio?
- ¿Qué permisos y roles necesitan definirse dentro del contexto de la organización, y cuáles no?
¿Qué modelos de autorización diferentes están disponibles en Logto?
Control de acceso basado en roles
RBAC (Control de Acceso Basado en Roles) es un método para otorgar permisos de usuario basados en sus roles, permitiendo una gestión efectiva del acceso a recursos.
Esta técnica común subyace al control de acceso y es un componente clave de las características de autorización de Logto. Como una plataforma de gestión de identidades integral, Logto ofrece soluciones personalizadas para varias capas y entidades, atendiendo a desarrolladores y empresas para diversas arquitecturas de productos.
Control de acceso basado en roles para API
Para proteger recursos generales de API que no son específicos de ninguna organización y no necesitan restricciones de contexto, la función API RBAC es ideal.
Solo registra la API y asigna permisos a cada recurso. Luego, controla el acceso a través de la relación entre roles y usuarios.
Los recursos de API, roles y permisos aquí están "democratizados" bajo un sistema de identidad unificado. Esto es bastante común en el producto B2C con menos jerarquía y no necesita un nivel muy profundo de aislamiento.
Control de acceso basado en roles para organizaciones
En el entorno B2B y multitenant, el aislamiento de inquilinos es necesario. Para lograr esto, se utilizan organizaciones como un contexto para el aislamiento, lo que significa que RBAC es efectivo solo cuando un usuario pertenece a una organización específica.
El RBAC para organizaciones se centra en controlar el acceso a nivel de organización en lugar de a nivel de API. Esto proporciona una flexibilidad significativa para la autogestión a nivel de organización a largo plazo, pero todavía dentro de un sistema de identidad unificado.
Una característica clave del RBAC para organizaciones es que los roles y permisos son generalmente los mismos en todas las organizaciones por defecto, lo que hace que el "template de organización" de Logto sea extremadamente significativo para mejorar la eficiencia del desarrollo. Esto se alinea con la filosofía compartida de las aplicaciones multitenant, donde las políticas de control de acceso e identidades son componentes comunes de infraestructura entre todos los inquilinos (inquilinos de aplicación), una práctica común en productos SaaS.
Conclusión
Este artículo proporciona todo lo que necesitas para comenzar a prepararte y configurar aplicaciones multitenant. Prueba Logto hoy y comienza a aplicar las mejores prácticas para el desarrollo de aplicaciones multitenant con organizaciones.