Es un modelo para la gestión de los permisos de los usuarios en múltiples cuentas, organizaciones o grupos.Con multi-tenancy, cada inquilino (por ejemplo, una cuenta o organización) opera en un entorno aislado, lo que requiere controles de acceso únicos adaptados a roles de usuario específicos dentro de ese entorno. Multi-tenant authorization Una de las formas más eficaces de implementar la autorización multi-teniente es combinándola con RBAC simplifica la gestión del acceso al asignar a los usuarios roles predefinidos que dictan sus permisos dentro de un entorno. Control de acceso basado en roles (RBAC) Control de acceso basado en roles (RBAC) Solo RBAC se enfrenta a tres grandes desafíos a medida que las aplicaciones se escalan y requieren más permisos de grano fino: Estando limitado a roles (y no a atributos y relaciones), el RBAC puede carecer de granularidad. Sus roles estáticos carecen de la capacidad de escalar a través de los inquilinos. A medida que crecen las aplicaciones, el número de roles puede volverse incontrolable, resultando en lo que se llama una “explosión de roles”. a resuelve estos problemas estructurando el acceso de los usuarios , permitiendo asignaciones de roles y permisos dinámicos dentro de entornos aislados. En lugar de asignar a un usuario un único rol global, sus permisos dependen de qué inquilino están en y qué papel tienen dentro de ese inquilino. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Piense en una plataforma de gestión de proyectos SaaS donde los usuarios pueden ser miembros de varias organizaciones, cada una con distintos niveles de acceso: Un usuario puede ser un administrador en una organización con control total, mientras que sólo un editor en otra, limitado a modificar tareas pero no a administrar usuarios. Piense en una plataforma de gestión de proyectos SaaS donde los usuarios pueden ser miembros de varias organizaciones, cada una con distintos niveles de acceso: El usuario puede ser un en una organización con control total, mientras que sólo un en otro, limitado a modificar tareas pero no a administrar usuarios. admin editor El RBAC multi-teniente asegura que los permisos se abarquen al entorno correcto sin complicaciones innecesarias. En esta guía, exploraremos el y mostrar cómo se puede implementar de manera eficiente utilizando . importance of Multi-Tenant Authorization Permit.io Permiso.io Hablaremos de cómo estructurar políticas, asignar roles por inquilino y hacer cumplir . fine-grained permissions Vamos a sumergirnos. ¿Por qué es importante la autorización multi-teniente? La autorización de varios inquilinos es útil para aplicaciones en las que los usuarios pertenecen a múltiples entornos independientes, cada uno con sus propias reglas de acceso - una ocurrencia común en la mayoría de las aplicaciones basadas en la nube modernas. Autorizaciones de manejo en entornos aislados Con multi-tenancy, cada usuario puede recibir un enfoque personalizado para su control de acceso basado en su inquilino. Como un usuario puede tener diferentes roles y responsabilidades en diferentes inquilinos, el uso de multi-tenancy permite que esos roles deben ser gestionados y ejecutados de forma independiente. Esto significa que podemos usar la autorización de varios inquilinos para mantener límites claros entre entornos, al tiempo que aseguramos que los usuarios tengan los permisos adecuados dentro de cada uno. Por ejemplo, considere a Es crucial imponer un control de acceso estricto para que un usuario de un cliente no pueda ver o modificar los datos de otro. cloud storage platform Pero ¿por qué no podemos solucionar esto solo con RBAC? Por qué el RBAC tradicional no es suficiente para la autorización de varios arrendatarios Mucho se puede decir sobre las limitaciones de RBAC. Cuando se trata de aplicaciones en la producción, RBAC puede resultar demasiado rígido y convertirse en demasiado complejo para escalar. Static Roles Don't Scale Across Tenants: In a traditional RBAC implementation, across an application.This means a user assigned an role might have access to edit all resources, even across tenants where they shouldn’t have permissions. roles usually apply globally Editor This problem can present itself as simply as: A project management app where a user is an in one team but should only have access in another. Editor Viewer Multi-Tenant RBAC allows roles to be scoped per tenant, so a user can be an Editor in one organization and a Viewer in another without unnecessary role duplication. Speaking of role duplication - The Role Explosion Problem A basic RBAC model can start simple: . As more users and resource types are introduced, a can occur. If we take our previous example where a single user needs to be an Editor in one team but a Viewer in another, you can easily end up with something like this: Admin, Editor, Viewer role explosion Editor_TeamA Editor_TeamB Viewer_TeamA Viewer_TeamB … and so on for every additional team / potential tenant. This makes the system hard to manage and difficult to update without breaking access rules. by dynamically assigning roles within each tenant instead of hardcoding them. Multi-Tenant RBAC removes the need for tenant-specific roles Multi-Tenant Authorization Requires Granularity RBAC is often too restricted when handling permissions at a granular level. It typically lacks built-in mechanisms to define resource-level or conditional access policies. Think of this policy: "Editors can only modify their own photos" How simple is that? The thing is - there’s no way RBAC can support such a policy without implementing additional logic. Especially at scale. Una aplicación de gestión de proyectos en la que un usuario es un en un solo equipo, pero debe tener acceso a otro. Editor Viewer "Los editores solo pueden modificar sus propias fotos" Antes de sumergirnos en la implementación y las mejores prácticas, mencionemos algunos modelos de multi-tenancy comúnmente utilizados: Modelos Multi-Tenant comunes La autorización de varios inquilinos se aplica a una amplia gama de aplicaciones.Aquí están algunas de las formas más comunes de estructurar los inquilinos: Cuentas: Usadas en aplicaciones SaaS de consumo, donde cada usuario pertenece a una cuenta independiente (por ejemplo, Google Drive, Dropbox). Organizaciones - Común en aplicaciones de negocios, donde una empresa (organización) tiene múltiples usuarios con roles variados (por ejemplo, Slack, Notion). Grupos: útiles para entornos colaborativos, donde los usuarios se agrupan en función de las necesidades de acceso compartido (por ejemplo, equipos de GitHub, espacios de trabajo de proyectos). En sistemas donde las empresas operan bajo un modelo de franquicia, cada franquicia funciona de forma independiente pero sigue una estructura central (por ejemplo, sistemas de gestión de restaurantes). Cada uno de estos modelos se beneficia de la autorización Multi-Tenant para garantizar el aislamiento adecuado y los permisos basados en roles por inquilino. Entendiendo los beneficios de la autorización de varios inquilinos, procederemos a discutir la implementación. Mejores prácticas para implementar la autorización multi-teniente Estrategias eficaces para gestionar roles, permisos y escalación en entornos aislados en aplicaciones multi-teniente. Planifica tu estrategia de autorización multi-teniente Antes de sumergirse en la implementación de cualquier cosa, es esencial planificar cómo funcionará su modelo multi-teniente. Aquí están algunos elementos clave que debe definir si está utilizando un modelo RBAC: separate, manageable access controls Usuarios: Individuos que acceden al sistema. Cada uno puede pertenecer a varios inquilinos. Alquileres: entornos separados en los que operan los usuarios (como cuenta, organización o espacio de trabajo). Roles: Niveles de permisos predefinidos asignados a usuarios dentro de un inquilino. Recursos: Objetos (por ejemplo, fotos, documentos) con los que los usuarios interactúan, controlados por permisos. Permisos: Reglas que definen las acciones que los roles pueden realizar en recursos específicos. Al abordar estas preguntas temprano, puede construir una Sistema de autorización adaptado a las necesidades de su solicitud. flexible and scalable Comprender los propósitos multi-teniente Desde a El sistema debe garantizar: single user can exist in multiple tenants Las asignaciones de roles son por inquilino: los permisos de un usuario deben estar estrechamente relacionados con su inquilino específico. Los recursos están vinculados a los inquilinos - Los recursos deben pertenecer a un inquilino específico. Los permisos se evalúan de forma dinámica: cuando un usuario hace una solicitud, el sistema verifica tanto su papel en el inquilino como la propiedad del recurso. Optimización de la autorización de varios arrendatarios: desconectar el esquema de los datos Un desafío común en los sistemas multi-teniente es gestionar cómo En los sistemas tradicionales, los roles y permisos a menudo están estrechamente asociados con los datos de la aplicación. Esto puede crear complicaciones cuando los permisos necesitan cambiar, ya que es posible que tenga que actualizar ambos Y el de sí mismo. roles and policies role assignment application data Para optimizar la escalabilidad: Almacenar roles, asignaciones y políticas en un sistema de autorización dedicado (como Permit.io), y mantener los datos de la aplicación separados de la lógica de autorización. Esta desacoplación le permite actualizar roles o permisos de forma dinámica sin tocar los datos básicos o la base de código de la aplicación. Use One Source of Truth (Punto de Decisión de Políticas) Uno de los conceptos críticos en la optimización de la autorización multi-teniente es el uso de un tomar decisiones políticas. single source of truth En lugar de almacenar información de rol y reglas de acceso dentro de cada servicio o base de datos de usuarios, el actúa como el punto central donde se toman todas las decisiones de acceso. Punto de Decisión Política (PDP) Punto de Decisión Política (PDP) Benefits of using a PDP: Consistencia: El PDP garantiza que todos los servicios en toda la aplicación se refieran al mismo conjunto de reglas al tomar decisiones de autorización. Evaluación dinámica de políticas: Los cambios a las políticas o asignaciones de roles solo necesitan ser actualizados en una ubicación, el PDP. Esta centralización elimina la necesidad de actualizar múltiples ubicaciones en su base de datos o código. Menor riesgo de error: Al confiar en un único punto de decisión centralizado, reduce el riesgo de permisos inconsistentes entre los inquilinos y las aplicaciones. Control de acceso basado en relaciones (ReBAC) Mientras proporciona una base sólida para la autorización de varios inquilinos, hay escenarios en los que puede ofrecer aún más control de acceso de grano fino. RBAC Control de acceso basado en relaciones (ReBAC) Control de acceso basado en relaciones (ReBAC) RBAC define permisos basados en roles asignados a los usuarios, pero dar un paso más allá mediante la definición de permisos basados en Esto es especialmente útil en situaciones en las que los permisos dependen de cómo los recursos están conectados o asociados entre sí. ReBAC relationships Por ejemplo, imaginemos a Cuando un usuario tiene acceso a un , y esa carpeta contiene varios documentos. Con RBAC, necesitaría definir roles como o Sin embargo, con Puedes simplificar esto diciendo: document management system folder Folder Editor Document Viewer ReBAC “Se permite a un usuario editar un documento si es editor de la carpeta a la que pertenece el documento”. “Se permite a un usuario editar un documento si es editor de la carpeta a la que pertenece el documento”. Esto permite asignaciones de permisos más dinámicas y sensibles al contexto sin duplicar roles para cada recurso. : Benefits of ReBAC Permisos contextuales: Permite el control de acceso basado en relaciones dinámicas (por ejemplo, un usuario es un editor en un proyecto, y por lo tanto tiene acceso a todas las tareas relacionadas). Reducción de la explosión de roles: no es necesario crear roles para cada combinación de tipo de usuario y de recurso, ya que las relaciones pueden definir el acceso de forma dinámica. Al extender RBAC con ReBAC, puede manejar donde las relaciones entre usuarios y recursos dictan permisos. complex access control scenarios Implementación de la autorización multi-teniente con Permiso.io Permiso.io ofrece una forma sencilla de implementar la autorización de varios inquilinos, permitiéndole definir roles, políticas y reglas de acceso en diferentes entornos. Permit.io if (user.role == admin && user.tenant == resource.tenant) { return true; } Tradicional y estática if El enfoque de la multi-tenancia. const permitted = await permit.check(user, "read", { resource: "document", tenant: "default" }); if (permitted) { return true; } y limpio permit.check() Función que verifica para multi-tenancy RBAC. Aquí está una amplia visión general de cómo se puede configurar la autorización RBAC de varios inquilinos en Permit.io: Define Roles, Resources, and Actions: To get started, first define your resources (e.g., documents, photos, tasks) and the actions that can be performed on them (e.g., create, read, update, delete). Add a (e.g., ) to represent the type of object you want to control access to. new resource blog Specify the resource's , which will be used in your API calls. key Define the users should be able to perform on the resource (e.g., create, read, update, delete). actions The screenshot shows an example where is the resource, and actions are defined for it. blog Define the Access Control Policy: You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like , , and are defined, and the policy is set up to specify which actions are permitted for each role. admin public Writer Define the Tenants in the Directory: Each tenant can have its own set of roles, permissions, and policies. To create tenants: Go to the screen and click on . Directory Settings Define the tenants you need (e.g., , , etc.). Tenant 1 Tenant 2 Create Users and Assign Roles: Once the tenants are defined, you can create users and assign them roles specific to each tenant. This ensures that the same user can have different roles in each tenant, depending on what permissions they need. To create a new user: Click in the screen. Add User Directory Assign the user a unique and other user details (e.g., email, first name). key In the section, you can assign the user roles specific to the tenant to which they belong. Permissions Per Tenant For instance, the user could be an in and a in , as shown in the screenshot: Admin Tenant 1 Writer Tenant 2 Aquí podemos ver a todos nuestros usuarios y qué roles tienen en cada inquilino a quien pertenecen: Algunos de los beneficios de usar Permit.io para la autorización de varios inquilinos incluyen: Gestión centralizada de políticas: Define y administre todas sus reglas y políticas de autorización desde una plataforma centralizada. Asignación de roles específicos al inquilino: asigna y gestiona fácilmente roles por inquilino, permitiendo a los usuarios tener diferentes roles en diferentes entornos (por ejemplo, administrador en un inquilino, Viewer en otro). Permisos de grano fino: Implemente permisos detallados para cada recurso y aplique permisos de grano fino complejos (como aquellos basados en atributos o relaciones) sin necesidad de lógica personalizada adicional. Soporte de ReBAC: Permit.io amplía el modelo tradicional de RBAC con ReBAC, lo que le permite definir permisos basados no solo en los roles de los usuarios, sino también en las relaciones entre los usuarios y los recursos. Summing Up: Autorización Multi-Tenant con RBAC En este blog hemos explorado la Cómo combinarlo con Permite una gestión de permisos de usuario más eficiente y escalable en entornos aislados. importance of multi-tenant authorization Role-Based Access Control (RBAC) Hemos discutido los desafíos de los RBAC tradicionales en las aplicaciones de varios inquilinos y cómo Multi-Tenant RBAC resuelve problemas como roles estáticos, explosión de roles y control de acceso de grano fino. Con la autorización de varios inquilinos, cada inquilino puede tener su propio control de acceso aislado, asegurando que los usuarios solo tienen acceso a lo que están autorizados para dentro de sus entornos específicos. Permite implementar la autorización de varios inquilinos de una manera más simplificada, gracias a la gestión centralizada de políticas, la asignación de roles específicos de los inquilinos, los permisos de grano fino y el soporte para el Control de acceso basado en relaciones (ReBAC). Permit.io What’s Next? Explore la documentación de Permit.io para comenzar a implementar la autorización de varios inquilinos en su aplicación. Únete a la comunidad de Permit.io para discutir las mejores prácticas y obtener apoyo.
