Compartir vía

Consideraciones sobre el uso de Azure Active Directory B2C en una arquitectura multiinquilino

  • Artículo

Azure Active Directory (Azure AD) B2C proporciona la identidad de negocio a consumidor como servicio. La identidad del usuario suele ser una de las principales consideraciones al diseñar una aplicación multiinquilino. La solución de identidad actúa como guardián de la aplicación, lo que garantiza que los inquilinos permanezcan dentro de los límites que les ha determinado. En este artículo se describen las consideraciones y los enfoques para usar Azure AD B2C en una solución multiinquilino.

Una de las razones más comunes a fin de usar Azure AD B2C es habilitar la federación de identidades para una aplicación. La federación de identidades es el proceso de establecer la confianza entre dos proveedores de identidades para que los usuarios puedan iniciar sesión con una cuenta preexistente. Si usa Azure AD B2C, puede implementar la federación de identidades para permitir que los usuarios inicien sesión con sus cuentas sociales o empresariales. Si usa la federación, los usuarios no necesitan crear una cuenta local independiente específica de la aplicación.

Si no conoce bien este tema, le recomendamos revisar los recursos siguientes:

Nota

En este artículo se describen dos conceptos con nombre similar: inquilinos de aplicación y inquilinos de Azure AD B2C.

El término inquilino de aplicación se usa para hacer referencia a sus inquilinos, que pueden ser sus clientes o grupos de usuarios.

Azure AD B2C también usa el concepto de inquilino en referencia a directorios individuales y el término multiinquilino se usa para hacer referencia a las interacciones entre varios inquilinos de Azure AD B2C. Aunque los términos son los mismos, los conceptos no lo son. Cuando se hace referencia a un inquilino de Azure AD B2C en este artículo, se usa el término completo inquilino de Azure AD B2C.

Identidad en las soluciones multiinquilino

En las soluciones multiinquilino, es habitual combinar varios servicios de identidad para lograr diferentes conjuntos de requisitos. Muchas soluciones tienen dos conjuntos distintos de identidades:

  • Identidades de cliente, que son para cuentas de usuario final. Controlan cómo los usuarios de los inquilinos obtienen acceso a las aplicaciones.
  • Identidades internas, que controlan cómo su propio equipo administra la solución.

Estos diferentes tipos de identidad también suelen usar distintos servicios de identidad. Azure AD B2C es un servicio de administración de identidad y acceso de clientes (CIAM) que usan los usuarios de los inquilinos para acceder a la solución. Microsoft Entra ID es un servicio de administración de identidades y acceso (IAM) que usted y su equipo usan para administrar los recursos de Azure y controlar la aplicación.

Veamos un ejemplo de una solución multiinquilino que ha creado Fabrikam. La solución usa una combinación de los dos servicios para satisfacer los requisitos de Fabrikam:

  • Fabrikam implementa Azure AD B2C para que los clientes (inquilinos) de la empresa puedan iniciar sesión en las aplicaciones.
  • Los empleados de Fabrikam usan el directorio Microsoft Entra de su organización para obtener acceso a su solución con fines de administración y administración. Usan las mismas identidades que utilizan para acceder a otros recursos de Fabrikam, como Microsoft Office.

En el siguiente diagrama, se ilustra este concepto:

Diagrama en el que se muestran dos aplicaciones con dos métodos de inicio de sesión.

Modelos de aislamiento

Al usar Azure AD B2C, debe decidir cómo aislar las cuentas de usuario entre distintos inquilinos de aplicación.

Debe tener en cuenta preguntas como las siguientes:

  • ¿Necesita federar los inicios de sesión en los proveedores de identidades del cliente? Por ejemplo, ¿necesita habilitar la federación para SAML, Microsoft Entra ID, proveedores de inicio de sesión social u otras fuentes?
  • ¿Usted o sus inquilinos tienen requisitos de residencia de datos?
  • ¿El usuario necesita acceder a más de un inquilino de aplicación?
  • ¿Necesita permisos complejos o control de acceso basado en rol (RBAC)?
  • ¿Quién inicia sesión en la aplicación? A menudo, las distintas categorías de usuarios se denominan roles de usuario.

En la tabla siguiente se resumen las diferencias entre los principales modelos de inquilinos para Azure AD B2C:

Consideración Inquilino de Azure AD B2C compartido Inquilino de Azure AD B2C con particiones verticales Un inquilino de Azure AD B2C por inquilino de aplicación
Aislamiento de datos Los datos de cada inquilino de aplicación se almacenan en un único inquilino de Azure AD B2C, pero solo los administradores pueden acceder a ellos. Los datos de cada inquilino de aplicación se distribuyen entre varios inquilinos de Azure AD B2C, pero solo los administradores pueden acceder a ellos. Los datos de cada inquilino de aplicación se almacenan en un inquilino de Azure AD B2C dedicado, pero solo los administradores pueden acceder a ellos.
Complejidad de la implementación Bajo De media a alta, en función de la estrategia de creación de particiones Muy alto
Límites que se deben tener en cuenta Solicitudes por inquilino de Azure AD B2C, solicitudes por dirección IP de cliente Una combinación de solicitudes, número de inquilinos de Azure AD B2C por suscripción y número de directorios para un único usuario, en función de la estrategia de creación de particiones Número de inquilinos de Azure AD B2C por suscripción, número máximo de directorios para un único usuario
Complejidad operativa Bajo De media a alta, en función de la estrategia de creación de particiones Muy alto
Número de inquilinos de Azure AD B2C necesarios Uno Entre uno y n, en función de la estrategia de creación de particiones n, donde "n" es el número de inquilinos de aplicación
Escenario de ejemplo Está creando una oferta de SaaS para los consumidores que no tienen requisitos de residencia de datos o son bajos, como un servicio de streaming de música o vídeo. Está creando una oferta de SaaS, como una aplicación de contabilidad y mantenimiento de registros para empresas. Debe admitir los requisitos de residencia de datos o muchos proveedores de identidades federados personalizados. Está creando una oferta de SaaS, como una aplicación de mantenimiento de registros gubernamentales para empresas. Los clientes exigen un alto grado de aislamiento de datos de otros inquilinos de aplicaciones.

Inquilino de Azure AD B2C compartido

Por lo general, es más fácil administrar un solo inquilino de Azure AD B2C compartido si los requisitos lo permiten. Debe mantener solo un inquilino a largo plazo y esta opción crea la sobrecarga más baja.

Nota

Se recomienda usar un inquilino de Azure AD B2C compartido para la mayoría de los escenarios.

Debe considerar un inquilino de Azure AD B2C compartido cuando:

  • No tiene requisitos de residencia de datos ni requisitos estrictos de aislamiento de datos.
  • Los requisitos de la aplicación se encuentran dentro de los límites de servicio de Azure AD B2C.
  • Si tiene proveedores de identidades federados, puede usar Detección del dominio de inicio para seleccionar automáticamente un proveedor con el que un usuario va a iniciar sesión. También se acepta que los usuarios seleccionen manualmente uno de una lista.
  • Tiene una experiencia de inicio de sesión unificada para todos los inquilinos de la aplicación.
  • Los usuarios finales necesitan acceder a más de un inquilino de aplicación mediante una sola cuenta.

En este diagrama se muestra el modelo de inquilino Azure AD B2C compartido:

Diagrama en el que se muestran tres aplicaciones que se conectan a un único inquilino compartido de Azure AD B2C.

Inquilinos de Azure AD B2C con particiones verticales

El aprovisionamiento de inquilinos de Azure AD B2C con particiones verticales es una estrategia diseñada para minimizar, siempre que sea posible, el número de inquilinos de Azure AD B2C necesarios. Es un punto intermedio entre los otros modelos de inquilinos. La creación de particiones verticales ofrece una mayor flexibilidad en la personalización de inquilinos específicos cuando es necesario. Pero no crea la sobrecarga operativa asociada al aprovisionamiento de un inquilino de Azure AD B2C para cada inquilino de aplicación.

Los requisitos de implementación y mantenimiento de este modelo de inquilinos son mayores que los de un único inquilino de Azure AD B2C, pero son menores a los que se exigirían si usara un inquilino de Azure AD B2C por inquilino de aplicación. Todavía tiene que diseñar e implementar una estrategia de implementación y mantenimiento para varios inquilinos en todo el entorno.

El particionamiento vertical es similar al patrón de particionamiento de datos. Para crear particiones verticales de los inquilinos de Azure AD B2C, debe organizar los inquilinos de la aplicación en grupos lógicos. Esta categorización de inquilinos suele denominarse estrategia de creación de particiones. La estrategia de creación de particiones debe basarse en un factor común y estable del inquilino de la aplicación, como la región, el tamaño o los requisitos personalizados de un inquilino de la aplicación. Por ejemplo, si su objetivo es resolver los requisitos de residencia de datos, puede decidir implementar un inquilino de Azure AD B2C para cada región que hospeda inquilinos de aplicación. O bien, si agrupa por tamaño, puede decidir localizar la mayoría de las identidades de los inquilinos de la aplicación en un único inquilino de Azure AD B2C, pero ubicar los inquilinos de aplicación de mayor tamaño en sus propios inquilinos de Azure AD B2C dedicados.

Importante

Evite basar la estrategia de creación de particiones en factores que puedan cambiar con el tiempo, ya que es difícil mover usuarios entre inquilinos de Azure AD B2C. Por ejemplo, si crea una oferta de SaaS que tiene varios SKU o niveles de producto, no debe crear particiones de los usuarios en función del SKU que seleccionen, ya que este podría cambiar si el cliente actualiza su producto.

Debe considerar la posibilidad de aprovisionar los inquilinos de Azure AD B2C mediante una estrategia con particiones verticales si:

  • Tiene requisitos de residencia de datos o bien necesita separar los usuarios por zonas geográficas.
  • Tiene muchos proveedores de identidades federados y no puede usar Detección del dominio de inicio para seleccionar automáticamente uno con el que un usuario inicie sesión.
  • La aplicación tiene, o puede tener, en cuenta la característica de multiinquilinos y sabe en qué inquilino de Azure AD B2C deben iniciar sesión los usuarios.
  • Cree que los inquilinos de aplicaciones de mayor tamaño podrían alcanzar los límites de Azure AD B2C.
  • Tiene una estrategia a largo plazo para implementar y mantener una cantidad, entre mediana y grande, de inquilinos de Azure AD B2C.
  • Tiene una estrategia para particionar los inquilinos de aplicaciones entre una o varias suscripciones de Azure para que funcionen dentro del límite en el número de inquilinos de Azure AD B2C que se pueden implementar en una suscripción de Azure.

En el diagrama siguiente se muestra el modelo de inquilino de Azure AD B2C con particiones verticales:

Diagrama en el que se muestran tres aplicaciones. Dos están conectadas a un inquilino compartido de Azure AD B2C. La tercera está conectada a su propio inquilino de Azure AD B2C.

Un inquilino de Azure AD B2C por inquilino de aplicación

Si aprovisiona un inquilino de Azure AD B2C para cada inquilino de aplicación, puede personalizar muchos factores para cada inquilino. Pero este enfoque supone un aumento significativo de la sobrecarga. Debe desarrollar una estrategia de implementación y mantenimiento para un número potencialmente elevado de inquilinos de Azure AD B2C.

También debe tener en cuenta los límites del servicio. Las suscripciones de Azure permiten implementar solo un número limitado de inquilinos de Azure AD B2C. Si necesita implementar más de lo que permite el límite, debe plantearse un diseño de suscripción adecuado para que pueda equilibrar los inquilinos de Azure AD B2C en varias suscripciones. También se aplican otros límites de Microsoft Entra, como la cantidad de directorios que un solo usuario puede crear y la cantidad de directorios a los que puede pertenecer un usuario.

Advertencia

Debido a la complejidad de este enfoque, se recomienda encarecidamente tener en cuenta en primer lugar los otros modelos de aislamiento. Esta opción se incluye aquí con objeto de dar una información lo más completa posible, pero no representa el enfoque adecuado para la mayoría de los casos de uso.

Una idea errónea común es suponer que, si usa el patrón de Sellos de implementación, debe incluir servicios de identidad en cada sello. Eso no es necesariamente cierto, y a menudo puede usar otro modelo de aislamiento en su lugar. Practique la diligencia y tenga una justificación comercial clara si usa este modelo de aislamiento. La sobrecarga de implementación y mantenimiento es considerable.

Debe plantearse la posibilidad de aprovisionar un inquilino de Azure AD B2C solo para cada inquilino de aplicación si:

  • Tiene requisitos estrictos de aislamiento de datos para los inquilinos de la aplicación.
  • Tiene una estrategia a largo plazo para implementar y mantener muchos inquilinos de Azure AD B2C.
  • Tiene una estrategia para particionar a los clientes entre una o varias suscripciones de Azure a fin de cumplir con el límite de inquilinos por suscripción de Azure AD B2C.
  • La aplicación tiene, o puede tener, en cuenta la característica de multiinquilinos y sabe en qué inquilino de Azure AD B2C deben iniciar sesión los usuarios.
  • Debe realizar una configuración personalizada para cada inquilino de la aplicación.
  • Los usuarios finales no necesitan acceder a más de un inquilino de la aplicación mediante la misma cuenta de inicio de sesión.

En el diagrama siguiente se muestra el uso de un inquilino de Azure AD B2C por inquilino de aplicación:

Diagrama en el que se muestran tres aplicaciones; cada una de ellas se conecta a su propio inquilino de Azure AD B2C.

Federación de identidades

Debe configurar cada proveedor de identidades federado, ya sea mediante un flujo de usuario o en una directiva personalizada. Normalmente, durante el inicio de sesión, los usuarios seleccionan qué proveedor de identidades quieren usar para autenticarse. Si usa un modelo de aislamiento de inquilino compartido o tiene muchos proveedores de identidades federados, considere la posibilidad de usar Detección del dominio de inicio para seleccionar automáticamente un proveedor de identidades durante el inicio de sesión.

También puede usar la federación de identidades como herramienta para administrar varios inquilinos de Azure AD B2C; para ello, federe los inquilinos de Azure AD B2C entre sí. Esto permite que la aplicación confíe en un único inquilino de Azure AD B2C. La aplicación no necesita saber que los clientes se dividen entre varios inquilinos de Azure AD B2C. Este enfoque se usa normalmente en el modelo de aislamiento con particiones verticales, cuando los usuarios tienen particiones por región. Debe tener en cuenta algunas consideraciones si adopta este enfoque. Para obtener información general sobre este enfoque, vea Soluciones de identidad global.

Detección del dominio de inicio

La Detección del dominio de inicio es el proceso de seleccionar automáticamente un proveedor de identidades federado para el evento de inicio de sesión de un usuario. Si selecciona automáticamente el proveedor de identidades del usuario, no es necesario solicitar al usuario que seleccione uno.

Detección del dominio de inicio es importante cuando se usa un inquilino compartido de Azure AD B2C y también permite a los clientes traer su propio proveedor de identidades federado. Es posible que quiera evitar un diseño en el que un usuario tenga que seleccionar de entre una lista de proveedores de identidades. Al hacerlo, se agrega complejidad al proceso de inicio de sesión. Además, un usuario podría seleccionar accidentalmente un proveedor incorrecto, lo que hace que se produzca un error en el intento de inicio de sesión.

Puede configurar Detección del dominio de inicio de varias maneras. El enfoque más común es usar el sufijo de dominio de la dirección de correo electrónico del usuario para determinar el proveedor de identidades. Por ejemplo, supongamos que Northwind Traders es un cliente de la solución multiinquilino de Fabrikam. La dirección de correo electrónico user@northwindtraders.com incluye el sufijo de dominio northwindtraders.com, que se puede asignar al proveedor de identidades federado de Northwind Traders.

Para obtener más información, vea Detección del dominio de inicio. Para obtener un ejemplo de cómo implementar este enfoque en Azure AD B2C, vea el repositorio de GitHub de ejemplos de Azure AD B2C.

Residencia de datos

Al aprovisionar un inquilino de Azure AD B2C, debe seleccionar, con el fin de la residencia de datos, una región en la cual implementar el inquilino. Esta opción es importante porque especifica la región en la que residen los datos del cliente cuando están en reposo. Si tiene requisitos de residencia de datos para un subconjunto de los clientes, plantéese usar la estrategia con particiones verticales.

Authorization

Para una solución de identidad segura, debe tener en cuenta la autorización además de la autenticación. Hay varios enfoques para usar la Plataforma de identidad de Microsoft a fin de crear una estrategia de autorización para la aplicación. En el ejemplo AppRoles se muestra cómo usar roles de aplicación de Azure AD B2C para implementar la autorización en una aplicación. También se describen enfoques de autorización alternativos.

No hay un enfoque único para la autorización y debe tener en cuenta las necesidades de la aplicación y los clientes cuando se decante por un enfoque.

Mantenimiento

Al planificar una implementación multiinquilino de Azure AD B2C, debe pensar en el mantenimiento a largo plazo de los recursos de Azure AD B2C. Un inquilino de Azure AD B2C, como el inquilino de Microsoft Entra de su organización, es un recurso que necesita crear, mantener, operar y proteger. Aunque la lista siguiente no es exhaustiva, debe tener en cuenta el mantenimiento en el que se incurre en áreas como estas:

  • Gobernanza de inquilinos. ¿Quién mantiene el inquilino de Azure AD B2C? ¿Qué roles elevados necesitan estos administradores? ¿Cómo se configuran las directivas de acceso condicional y la autenticación multifactor para los administradores? ¿Cómo se supervisa el inquilino de Azure AD B2C a largo plazo?
  • Configuración del recorrido del usuario. ¿Cómo se implementan los cambios en los inquilinos de Azure AD B2C? ¿Cómo se prueban los cambios en los flujos de usuario o las directivas personalizadas antes de implementarlos?
  • Proveedores de identidades federados. ¿Necesita agregar o quitar proveedores de identidades a lo largo del tiempo? Si permite que cada uno de sus clientes traiga su propio proveedor de identidades, ¿cómo administra esto a gran escala?
  • Registros de aplicaciones. Muchos registros de aplicaciones Microsoft Entra utilizan un secreto de cliente o un certificado para la autenticación. ¿Cómo rota estos secretos o certificados cuando necesita hacerlo?
  • Claves de directiva. Si usa directivas personalizadas, ¿cómo rota las claves de directiva cuando necesita hacerlo?
  • Credenciales de usuario. ¿Cómo administra la información y las credenciales del usuario? ¿Qué ocurre si uno de los usuarios está bloqueado u olvida una contraseña, y requiere la intervención del administrador o el servicio de atención al cliente?

Recuerde que debe tener en cuenta estas preguntas para cada inquilino de Azure AD B2C que implemente. También debe tener en cuenta cómo cambian los procesos cuando tiene varios inquilinos de Azure AD B2C que debe mantener. Por ejemplo, la implementación manual de cambios de directivas personalizadas en un inquilino de Azure AD B2C es sencilla, pero implementarlos manualmente en cinco inquilinos consume mucho tiempo y supone un riesgo.

Implementaciones y DevOps

Un proceso de DevOps bien definido puede ayudarle a minimizar la sobrecarga necesaria para mantener los inquilinos de Azure AD B2C. Debe implementar prácticas de DevOps al principio del proceso de desarrollo. Lo ideal es intentar automatizar todas las tareas de mantenimiento, o la mayoría de ellas, incluida la implementación de cambios en las directivas personalizadas o los flujos de usuario. También debe planificar la creación de varios inquilinos de Azure AD B2C para probar progresivamente los cambios en entornos inferiores antes de implementarlos en los inquilinos de producción. Las canalizaciones de DevOps pueden realizar estas actividades de mantenimiento. Puede usar Microsoft Graph API para administrar mediante programación los inquilinos de Azure AD B2C.

Para obtener más información sobre las implementaciones automatizadas y la administración de Azure AD B2C, vea los recursos siguientes.

Importante

Algunos de los puntos de conexión que se usan para administrar Azure AD B2C mediante programación no están disponibles con carácter general. Las API de la versión beta de Microsoft Graph están sujetas a cambios en cualquier momento y están sujetas a términos del servicio de versión preliminar.

Comparación de Microsoft Entra B2B con Azure AD B2C

La colaboración B2B de Microsoft Entra es una característica de Microsoft Entra External ID que puede usar para invitar a usuarios invitados a su inquilino organizacional de Microsoft Entra para que pueda colaborar con ellos. Normalmente, se usa la colaboración B2B cuando se necesita conceder a un usuario externo, como un proveedor, el acceso a los recursos del inquilino de Microsoft Entra.

Azure AD B2C es un producto único aparte de Microsoft Entra External ID que proporciona un conjunto diferente de características. Azure AD B2C está pensado para que lo usen los clientes del producto. Su inquilino de Azure AD B2C es distinto del inquilino de Microsoft Entra de su organización.

Dependiendo de los escenarios y las personas de sus usuarios, es posible que necesite utilizar Microsoft Entra B2B, Azure AD B2C o incluso ambos al mismo tiempo. Por ejemplo, si su aplicación necesita autenticar varios tipos de usuarios, como personal de su organización, usuarios que trabajan para un proveedor y clientes, todos dentro de la misma aplicación, puede usar Microsoft Entra B2B y Azure AD B2C juntos para cumplir con esto. requisito.

Para más información, consulte:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes