Arquitectura de múltiples organizaciones

Una guía de integración para arquitecturas multiinquilino que deben admitir instancias de aplicación para múltiples organizaciones de Auth0.

Existen múltiples casos de uso en los que los usuarios pertenecen a organizaciones de terceros que se han registrado para usar los servicios que usted ofrece. Estos usuarios pueden ser empleados de una organización de terceros, clientes o una combinación de ambos. Sea cual sea la situación, esta guía le proporcionará una descripción general de los casos de uso comunes de las aplicaciones multiinquilino.

Las aplicaciones B2B buscan crear una experiencia de usuario agradable para los empleados y clientes de las empresas a las que prestan servicio. Para lograrlo, los proveedores de servicios en entornos B2B suelen permitir agregar la marca de cada una de las organizaciones que usan su servicio. Por ejemplo, supongamos que usted trabaja para AwesomeSaaS (una empresa de software SaaS) y que su empresa usa Human0, una aplicación de RR. HH. para gestionar beneficios y otras funciones de RR. HH. Usted accede a su aplicación de RR. HH. y, cuando inicia sesión, la experiencia de Login se personaliza para mostrar el logotipo de AwesomeSaaS y usar los colores de AwesomeSaaS.

Como proveedor de servicios B2B que diseña una integración con Auth0, deberá considerar si sus clientes (es decir, organizaciones de terceros) permitirán que usuarios de otras organizaciones inicien sesión en su instancia de la aplicación y si esos usuarios deben compartirse entre organizaciones o aislarse en una sola organización.

Comencemos presentando un par de aplicaciones de ejemplo que ilustran los distintos casos de uso. Travel0 es una empresa ficticia que ofrece servicios de agencia de viajes en línea. Travel0 tiene varias aplicaciones, pero, para los fines de este ejercicio, nos centraremos en dos aplicaciones que se comercializan directamente a organizaciones:

• Travel0 Corporate Booking: Proporciona a las organizaciones una aplicación en línea en la que sus empleados pueden iniciar sesión y reservar viajes de trabajo. Entre las organizaciones que son clientes de esta aplicación se incluyen:

  • Hoekstra & Associates: Un pequeño bufete de abogados con solo unos pocos empleados. No tienen un departamento de TI y no disponen del tiempo ni de la capacidad necesarios para aprender a configurar un Proveedor de identidad (IdP) corporativo.
  • Gupta & Smith Law: Un bufete de abogados más grande, pero tampoco tienen un departamento de TI y no disponen del tiempo ni de la capacidad necesarios para aprender a configurar un IdP corporativo.
  • MetaHexa Bank: Una gran organización financiera. Ofrecen servicios bancarios y de seguros y tienen su propio IdP.
  • Many Student University (MSU): Una gran universidad con varios campus, donde cada campus tiene su propio IdP.

• Travel0 Adventure Management: Permite a las organizaciones crear y promocionar aventuras, como rafting en aguas bravas. Los guías (que son trabajadores autónomos o empleados de alguna organización externa de viajes o eventos) pueden usar esta aplicación para crear una cuenta y gestionar la programación de las aventuras. Entre las organizaciones que son clientes de esta aplicación se incluyen:

  • AdventureZ: Un gran organizador de tours y eventos. Tienen su propio IdP, que usan para sus empleados. Rara vez necesitan trabajadores autónomos porque cuentan con suficientes guías en plantilla, algunos de los cuales solo trabajan durante las temporadas de mayor actividad. También facilitan que sus guías puedan trabajar como autónomos para otras empresas.
  • Rocky Mountain High Adventures: Un nuevo grupo que entra en el mercado por primera vez. Los cofundadores organizan tours; recurren a trabajadores autónomos para obtener ayuda durante las temporadas de mayor actividad.
  • Suzie’s Rafting and Ziplines: Esta empresa lleva mucho tiempo en el mercado. Tiene una plantilla de guías que se encarga de la mayoría de sus eventos, pero también contrata trabajadores autónomos cuando hay mucha actividad.

​

Terminología

Muchas de las palabras utilizadas en la guía proporcionada pueden tener varios significados. Tómese un momento para leer cada definición para que, al revisar los ejemplos, quede claro quién desempeña cada función:

• Tenant de Auth0 (también conocido como Servidor de autorización): Tenant que crea en Auth0. Es una instancia de un Servidor de autorización y representa uno o más dominios de usuario.
• Organizaciones de Auth0: Se refiere a la funcionalidad del Tenant de Auth0 diseñada para admitir organizaciones. Una instancia de una Organización de Auth0 normalmente hará referencia a un cliente específico suyo.
• Empleado: Persona que trabaja para su empresa. Normalmente tendrá una cuenta en su Proveedor de identidad (IdP) y puede necesitar acceso de administrador a una o más instancias de Tenant de Organización. Solo usaremos el término Empleado para referirnos a empleados de su empresa. Para los usuarios que pertenecen a las Organizaciones de sus clientes, consulte Usuario de la Organización.
• Proveedor de identidad (IdP): Servicio, como Auth0, que administra la autenticación de usuarios y, opcionalmente, proporciona información del perfil de usuario y/o administración de credenciales. El servicio también puede delegar la validación de credenciales y la administración de perfiles mediante el uso de un IdP de terceros (como Azure AD, Google, Facebook, etc.).
• Organización: Empresa de terceros que es uno de sus clientes. Puede referirse a una instancia de organización creada para su aplicación como un tenant; nos referiremos a ella como un Tenant de Organización para evitar confundirla con un Tenant de Auth0.
• Tenant de Organización: Se refiere a un tenant que se ha creado para su cliente como parte de la suscripción o el aprovisionamiento de su aplicación. Esto es diferente de un Tenant de Auth0.
• Usuario de la Organización: Persona que inicia sesión en la aplicación como miembro de una organización. Puede ser un empleado (de la organización) o un cliente. Cualquier usuario al que se haga referencia en un contexto de organización puede considerarse un Usuario de la Organización.

​

Aislamiento de usuarios

Es importante determinar el tipo de aplicación que proporciona en lo que respecta al aislamiento de usuarios por organización. Existen dos enfoques fundamentales sobre cómo y dónde se almacenan estos usuarios: usuarios aislados por organización y usuarios compartidos entre organizaciones.

El diagrama de flujo anterior describe el proceso de toma de decisiones. También debe considerar si se requiere acceso administrativo para una instancia de organización. Podría tratarse de un empleado de su organización que actúa como administrador de una o más organizaciones, o de un tercero que presta servicios de asistencia técnica o similares.

Las siguientes secciones proporcionan detalles sobre cada enfoque de aislamiento de usuarios por organización. Preste especial atención a los escenarios atípicos asociados a cada uno (es decir, cuando los usuarios necesitan acceso a más de una organización), ya que este tipo de casos de uso suele determinar qué enfoque se ajusta mejor a sus requisitos.

​

Usuarios aislados por Organización

Cada organización tiene su propio conjunto de usuarios, y los usuarios no pueden ni deben poder acceder a otras organizaciones. Si intentan hacerlo, se les debe rechazar por no estar autorizados. Si lo desea, puede exigir a sus usuarios que creen una cuenta independiente para cada organización a la que pertenezcan. Esa misma persona se consideraría, en la práctica, dos o más usuarios diferentes.

En este escenario, un usuario está vinculado directamente a la organización a la que pertenece o a la que tiene acceso. Los usuarios tienen dos opciones para iniciar sesión: A) crear credenciales en un almacenamiento de identidades aprovisionado para la organización correspondiente (es decir, una conexión de base de datos de UserID/Password en su Tenant de Auth0), o B) iniciar sesión con el IdP de su propia organización. En este caso de uso, no tendría sentido que un usuario formara parte de varias organizaciones, y la mejor práctica sería crear una identidad independiente para cada organización. Tomando Travel0 Corporate Booking como ejemplo, el siguiente diagrama muestra cómo sería esto:

Sally es una usuaria típica: es empleada de MetaHexa Bank y solo puede acceder a la instancia de Travel0 Corporate Booking de MetaHexa Bank.

Pat, por otro lado, es una usuaria atípica. Pat es asistente jurídica autónoma, por lo que trabaja tanto para Hoekstra & Associates como para Gupta & Smith Law; accederá a la instancia de Travel0 Corporate Booking de cada una con una identidad de usuario independiente. Una de las muchas ventajas de este enfoque es limitar la posibilidad de errores al obligar a Pat a crear dos perfiles independientes: uno para cada bufete. Cuando Pat reserva viajes, debe iniciar sesión por separado en la instancia de la organización específica para poder realizar la reserva.

La situación de Pat probablemente sea un caso de uso poco frecuente. Sin embargo, ilustra lo que debe tenerse en cuenta al determinar los requisitos de aislamiento de usuarios. Si desea aislar a los usuarios en la organización con la que están asociados, esto requiere crear identidades de usuario independientes. En este caso, Pat tiene una identidad cuando accede a la instancia de Travel0 Corporate Booking de Hoekstra & Associates y otra distinta para acceder a la instancia de Travel0 Corporate Booking de Gupta & Smith Law.

​

Casos de uso al aislar por organización

Las aplicaciones que aíslan a los usuarios por organización suelen admitir tres casos de uso distintos. Para los ejemplos de esta sección, usaremos los escenarios de la aplicación Travel0 Corporate Booking descritos en nuestra introducción. Travel0 es el cliente de Auth0.

• Organizaciones que no tienen su propio IdP o no saben cómo usarlo. Suelen ser organizaciones más pequeñas que no cuentan con un departamento de TI disponible para configurar el inicio de sesión único (SSO) con el Proveedor de identidad (IdP) de la organización, o bien no tienen un IdP de organización adecuado para esta tarea. En nuestro ejemplo de Travel0 Corporate Booking, Hoekstra & Associates es una organización de este tipo.
• Organizaciones que prefieren configurar su propio IdP para que sus empleados no tengan que crear un nuevo conjunto de credenciales para su aplicación. La mayoría de las organizaciones entran en esta categoría. En nuestro ejemplo de Travel0 Corporate Booking, MetaHexa Bank es una organización de este tipo.
• Organizaciones que requieren múltiples opciones de autenticación. Entre los ejemplos de este tipo de organización se incluyen aquellas que adquieren con frecuencia nuevas empresas, organizaciones como las escuelas que permiten que el personal y los padres inicien sesión en la misma aplicación, y organizaciones que invitan a partners o clientes a iniciar sesión en su instancia de la aplicación (es decir, organizaciones B2B2C). En nuestros ejemplos, Many Student University (MSU) sería una organización de este tipo.

Para los dos primeros tipos de organizaciones, la solución suele ser bastante sencilla. Estas organizaciones se consideran organizaciones con un único IdP, y el enfoque es casi siempre el mismo. Para obtener más información, consulte Organizaciones con un solo proveedor de identidad.

Las organizaciones que tienen más de un IdP dentro de la organización suelen presentar un mayor grado de complejidad, pero hay algunos enfoques que pueden minimizarla. Para obtener más información, consulte Organizaciones con varios proveedores de identidad.

​

Usuarios compartidos entre organizaciones

Un usuario puede pertenecer a más de una organización, y sería conveniente que no tuviera que contar con una identidad/cuenta distinta al pasar de una organización a otra. En esos casos, las organizaciones pueden seguir usando su propio IdP.

En este escenario, un usuario deja de estar vinculado directamente a la organización a la que pertenece o a la que tiene acceso. Ahora, los usuarios tienen dos opciones para iniciar sesión: A) crear credenciales en un almacenamiento de identidades aprovisionado de forma centralizada (es decir, en una única conexión de base de datos de usuario/contraseña en su Tenant de Auth0), en lugar de hacerlo en un almacén de identidades asignado específicamente en su Tenant de Auth0 para la organización, o B) iniciar sesión mediante el IdP de su propia organización. Una vez que un usuario tiene una identidad, se le concede permiso para acceder a cada una de las organizaciones a las que debe tener acceso. Esto puede significar acceso a una sola organización o a más de una. Los usuarios deberán entender que, cuando se les solicite iniciar sesión, pueden usar las mismas credenciales para acceder a la instancia de cada organización. Si usamos Travel0 Adventure Management como ejemplo, el diagrama anterior muestra cómo se vería esto.

Jonno es un usuario típico. Jonno es empleado de Suzie’s Rafting and Ziplines. Jonno solo puede iniciar sesión en la instancia de Travel0 Adventure Management aprovisionada para crear y guiar aventuras para Suzie’s Rafting and Ziplines. Las credenciales de Jonno se almacenan en una conexión de base de datos asociada al Tenant de Auth0 de Travel0 o en el IdP de Suzie’s Zipline and Rafting (según quieran o no administrar las identidades de sus usuarios).

Sumana es una usuaria atípica. Sumana es empleada de AdventureZ, pero, como AdventureZ también coordina oportunidades para trabajadores autónomos para las empresas de guías más pequeñas durante las temporadas de mayor demanda, Sumana ha sido invitada a unirse a Rocky Mountain High Adventures como freelancer. Sumana está autorizada a iniciar sesión tanto en la instancia de AdventureZ como en la de Rocky Mountain de Travel0 Adventure Management. Sin embargo, como nunca ha sido invitada como guía a Suzie’s Rafting and Ziplines, no está autorizada para acceder a esa instancia.

Sumana necesita tener la misma identidad para ambas organizaciones porque guiar aventuras implica el uso de un sistema de calificación, y las calificaciones de Sumana deben mantenerse y combinarse entre las organizaciones con las que trabaja. Las credenciales de Sumana, al igual que las de Jonno, se almacenan en una conexión de base de datos asociada al Tenant de Auth0 de Travel0 o en el IdP de AdventureZ (según AdventureZ quiera o no administrar las identidades de sus usuarios). El lugar donde se almacenan sus credenciales no afecta a las instancias de organización a las que tiene acceso.

​

Acceso administrativo a las Organizaciones

Hay casos en los que deberá proporcionar acceso administrativo en todas sus organizaciones. Normalmente, esto será para tareas administrativas ajenas a la gestión del perfil/la cuenta del usuario (como se describe en Gestión de perfiles), y puede que necesite dar acceso tanto a sus empleados como a terceros.

Práctica recomendada

Habilite siempre la Autenticación multifactor (MFA) para los administradores del Tenant de Auth0 que tengan acceso a través del Auth0 Dashboard. Tenga en cuenta que debe seguir un proceso distinto para habilitar MFA para un administrador del Tenant de Auth0 que para habilitar MFA para el propio Tenant de Auth0. Para obtener más información sobre cómo habilitar MFA para un administrador del Tenant de Auth0, consulte Manage Dashboard Access with Multi-factor Authentication.

El Auth0 Dashboard puede configurarse mediante control de acceso basado en roles, lo que le permitirá definir roles específicos para sus empleados en toda la implementación de su Tenant de Auth0. Incluso puede aprovechar su propio IdP corporativo para proporcionar autenticación de administrador del Tenant de Auth0 a sus empleados, así como acceso ampliado de administrador del Tenant a terceros de confianza.

Para otros tipos de acceso administrativo, normalmente querrá crear su propia API o aplicación, que utilizará junto con la Management API de Auth0. No se recomienda proporcionar acceso administrativo a su Tenant de Auth0 a través del Auth0 Dashboard a un amplio conjunto de usuarios. Aunque crear una aplicación o API de este tipo queda fuera del alcance de este documento, se recomienda que solicite ayuda a Auth0 Professional Services antes de embarcarse en una iniciativa de este tipo.

​

Más información

• Organizaciones con un solo proveedor de identidad
• Organizaciones con varios proveedores de identidad