Cómo implementar la autorización de varios inquilinos con control de acceso basado en roles

Multi-tenant authorizationEs 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.

Una de las formas más eficaces de implementar la autorización multi-teniente es combinándola conControl de acceso basado en roles (RBAC)RBAC simplifica la gestión del acceso al asignar a los usuarios roles predefinidos que dictan sus permisos dentro de un entorno.

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”.

amulti-tenant RBAC modelresuelve estos problemas estructurando el acceso de los usuariosper tenant, 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.

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 unadminen una organización con control total, mientras que sólo uneditoren otro, limitado a modificar tareas pero no a administrar usuarios.

El RBAC multi-teniente asegura que los permisos se abarquen al entorno correcto sin complicaciones innecesarias.

En esta guía, exploraremos elimportance of Multi-Tenant Authorizationy mostrar cómo se puede implementar de manera eficiente utilizandoPermit.io.

Hablaremos de cómo estructurar políticas, asignar roles por inquilino y hacer cumplirfine-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 acloud storage platformEs crucial imponer un control de acceso estricto para que un usuario de un cliente no pueda ver o modificar los datos de otro.

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, roles usually apply globally across an application.This means a user assigned an Editor role might have access to edit all resources, even across tenants where they shouldn’t have permissions.

  This problem can present itself as simply as:

  
  

  A project management app where a user is an Editor in one team but should only have Viewer access in another.

  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: Admin, Editor, Viewer. As more users and resource types are introduced, a role explosion 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:

  • 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.

  Multi-Tenant RBAC removes the need for tenant-specific roles by dynamically assigning roles within each tenant instead of hardcoding them.

  
  

• 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 unEditoren un solo equipo, pero debe tenerVieweracceso a otro.

"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:

1. Cuentas: Usadas en aplicaciones SaaS de consumo, donde cada usuario pertenece a una cuenta independiente (por ejemplo, Google Drive, Dropbox).
2. Organizaciones - Común en aplicaciones de negocios, donde una empresa (organización) tiene múltiples usuarios con roles variados (por ejemplo, Slack, Notion).
3. 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).
4. 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.separate, manageable access controlsAquí están algunos elementos clave que debe definir si está utilizando un modelo RBAC:

• 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 unaflexible and scalableSistema de autorización adaptado a las necesidades de su solicitud.

Comprender los propósitos multi-teniente

Desde asingle user can exist in multiple tenantsEl sistema debe garantizar:

1. Las asignaciones de roles son por inquilino: los permisos de un usuario deben estar estrechamente relacionados con su inquilino específico.
2. Los recursos están vinculados a los inquilinos - Los recursos deben pertenecer a un inquilino específico.
3. 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ómoroles and policiesEn 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 ambosrole assignmentY elapplication datade sí mismo.

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 unsingle source of truthtomar decisiones políticas.

En lugar de almacenar información de rol y reglas de acceso dentro de cada servicio o base de datos de usuarios, elPunto de Decisión Política (PDP)actúa como el punto central donde se toman todas las decisiones de acceso.

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)

MientrasRBACproporciona una base sólida para la autorización de varios inquilinos, hay escenarios en los queControl de acceso basado en relaciones (ReBAC)puede ofrecer aún más control de acceso de grano fino.

RBAC define permisos basados en roles asignados a los usuarios, peroReBACdar un paso más allá mediante la definición de permisos basados enrelationshipsEsto es especialmente útil en situaciones en las que los permisos dependen de cómo los recursos están conectados o asociados entre sí.

Por ejemplo, imaginemos adocument management systemCuando un usuario tiene acceso a unfolder, y esa carpeta contiene varios documentos. Con RBAC, necesitaría definir roles comoFolder EditoroDocument ViewerSin embargo, conReBACPuedes simplificar esto diciendo:

“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 manejarcomplex access control scenariosdonde las relaciones entre usuarios y recursos dictan permisos.

Implementación de la autorización multi-teniente conPermiso.io

Permit.ioofrece una forma sencilla de implementar la autorización de varios inquilinos, permitiéndole definir roles, políticas y reglas de acceso en diferentes entornos.

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 new resource (e.g., blog) to represent the type of object you want to control access to.
  • Specify the resource's key, which will be used in your API calls.
  • Define the actions users should be able to perform on the resource (e.g., create, read, update, delete).
  • The screenshot shows an example where blog is the resource, and actions are defined for it.

• Define the Access Control Policy:

  You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like admin, public, and Writer are defined, and the policy is set up to specify which actions are permitted for each role.

  

• Define the Tenants in the Directory:

  Each tenant can have its own set of roles, permissions, and policies.

  To create tenants:

  • Go to the Directory screen and click on Settings.
  • Define the tenants you need (e.g., Tenant 1, Tenant 2, etc.).

  

  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 Add User in the Directory screen.

  • Assign the user a unique key and other user details (e.g., email, first name).

  • In the Permissions Per Tenant section, you can assign the user roles specific to the tenant to which they belong.

    For instance, the user could be an Admin in Tenant 1 and a Writer in Tenant 2, as shown in the screenshot:

    
    

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 laimportance of multi-tenant authorizationCómo combinarlo conRole-Based Access Control (RBAC)Permite una gestión de permisos de usuario más eficiente y escalable en entornos aislados.

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.

Permit.ioPermite 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).

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.