Compartir a través de

Enfoques de arquitectura para identidad en soluciones multiinquilino

Casi todas las soluciones multiinquilino requieren un sistema de identidad. En este artículo se describen los componentes comunes de la identidad, incluida la autenticación y la autorización, y cómo puede aplicar estos componentes en una solución multiinquilino.

Nota:

Antes de empezar a crear un sistema de identidad para una solución multiinquilino, consulte Consideraciones de arquitectura para la identidad en una solución multiinquilino.

Autenticación

La autenticación es el proceso que establece la identidad de un usuario. Al crear una solución multiinquilino, tenga en cuenta los distintos enfoques para distintos aspectos del proceso de autenticación.

Federación

Es posible que tenga que federarse con proveedores de identidades externos (IDP). Puede usar la federación para habilitar los escenarios siguientes:

  • Inicio de sesión social, que permite a los usuarios iniciar sesión con su cuenta de Google, Facebook, GitHub o microsoft personal.

  • Directorios específicos del inquilino, que permiten a los inquilinos federar la aplicación con sus propios IDP para que no necesiten administrar cuentas en varios lugares

Para obtener más información, consulte patrón de identidad federada.

Si elige admitir IdP específicos para inquilinos, asegúrese de aclarar qué servicios y protocolos admite la aplicación. Por ejemplo, determine si se debe admitir el protocolo OpenID Connect y el protocolo de lenguaje de marcado de aserción de seguridad, o si se debe limitar la federación a las instancias de Id. de Microsoft Entra.

Al implementar un IdP, tenga en cuenta la escala y los límites que pueden aplicarse. Por ejemplo, el IdP podría poder federarse solo con un número limitado de otros IdP.

Considere también la posibilidad de proporcionar federación como una característica que solo se aplique a los clientes en un nivel de producto superior.

Inicio de sesión único

El inicio de sesión único permite a los usuarios cambiar entre aplicaciones sin problemas sin necesidad de volver a autenticarse en cada punto.

Cuando los usuarios visitan una aplicación, la aplicación los dirige a un IdP. Si el IdP detecta una sesión existente, emite un nuevo token sin necesidad de que los usuarios interactúen con el proceso de inicio de sesión. Un modelo de identidad federada admite el inicio de sesión único al permitir que los usuarios usen una sola identidad en varias aplicaciones.

En una solución multiarrendatario, podrías habilitar otra forma de inicio de sesión único. Si los usuarios tienen autorización para acceder a datos en varias entidades, podría necesitar proporcionar una experiencia fluida cuando cambien su contexto de una entidad a otra. Tenga en cuenta si la solución debe admitir transiciones sin problemas entre inquilinos. Si es así, considere si el IdP debe volver a emitir tokens con información específica del inquilino. Por ejemplo, cuando un usuario inicia sesión en Azure Portal, puede cambiar entre distintos directorios de identificadores de Microsoft Entra. Esta transición desencadena la reautenticación y genera un nuevo token a partir de la instancia de Id. de Microsoft Entra recién seleccionada.

Evaluación del riesgo de inicio de sesión

Las plataformas de identidad modernas admiten una evaluación de riesgos durante el proceso de inicio de sesión. Por ejemplo, si un usuario inicia sesión desde una ubicación o dispositivo poco habitual, el sistema de autenticación podría requerir comprobaciones de identidad adicionales, como la autenticación multifactor (MFA), antes de permitir que la solicitud de inicio de sesión siga adelante.

Considere si los inquilinos pueden tener diferentes directivas de riesgo que deban aplicarse durante el proceso de autenticación. Por ejemplo, si tiene algunos inquilinos en un sector altamente regulado, es posible que tengan distintos perfiles de riesgo y requisitos que los inquilinos que trabajan en entornos menos regulados. O bien, puede permitir que los inquilinos con niveles de precios más altos especifiquen directivas de inicio de sesión más restrictivas que los inquilinos que adquieren niveles más bajos de su servicio.

Si necesita admitir diferentes directivas de riesgo para cada inquilino, el sistema de autenticación debe saber a qué inquilino inicia sesión el usuario para que pueda aplicar las directivas correctas.

Si el IdP incluye estas funcionalidades, considere la posibilidad de usar las características nativas de evaluación de riesgos de inicio de sesión del IdP. Estas características pueden ser complejas y propensas a errores si las implementa usted mismo.

Como alternativa, si federas con los IdP de los arrendatarios, se pueden aplicar sus directivas de mitigación de inicios de sesión de riesgo, lo que les permite controlar las políticas y los mecanismos de aplicación. Por ejemplo, si se requieren dos desafíos de MFA, uno del IdP principal del usuario y otro del suyo propio, puede dificultar el proceso de inicio de sesión. Asegúrese de comprender cómo interactúa la federación con cada uno de los IdP de su organización y las políticas que tienen implementadas.

Suplantación

La suplantación permite a un usuario asumir la identidad de otro usuario sin usar las credenciales de ese usuario.

La suplantación es generalmente peligrosa y puede ser difícil de implementar y controlar. Sin embargo, en algunos escenarios, se requiere la suplantación. Por ejemplo, si opera en un entorno de software como servicio (SaaS), es posible que el personal del departamento de soporte técnico deba asumir la identidad de un usuario para que pueda iniciar sesión como usuario y solucionar un problema.

Si implementa la suplantación, considere cómo auditar su uso. Asegúrese de que los registros incluyan tanto el usuario que realizó la acción como el identificador del usuario que suplantaron.

Algunas plataformas de identidad admiten la suplantación, ya sea como una característica integrada o mediante código personalizado. Por ejemplo, puede agregar una reclamación personalizada en Microsoft Entra External ID para el identificador de usuario suplantado, o bien puede reemplazar la reclamación de identificador de sujeto en los tokens emitidos.

Autorización

La autorización es el proceso de determinar lo que un usuario puede hacer.

Los datos de autorización se pueden almacenar en varios lugares, incluidas las siguientes ubicaciones:

  • En su IdP: Por ejemplo, si usa Microsoft Entra ID como su IdP, puede usar funciones como roles de aplicación y grupos para almacenar información de autorización. Luego, tu aplicación puede usar las reclamaciones del token asociadas para aplicar tus reglas de autorización.

  • En la aplicación: Puede crear su propia lógica de autorización y, a continuación, almacenar información sobre lo que cada usuario puede hacer en una base de datos o en un sistema de almacenamiento similar. Después, puede diseñar controles específicos para la autorización de nivel de recurso o basada en roles.

En la mayoría de las soluciones multiinquilino, el cliente o el inquilino administra las asignaciones de roles y permisos, y no el proveedor del sistema multiinquilino.

Adición de información sobre la identidad y el rol del inquilino a los tokens

Determine qué partes de la solución deben controlar las solicitudes de autorización. Evalúe si se permite que un usuario acceda a los datos de un inquilino específico.

Un enfoque común es que el sistema de identidad inserte una notificación de id. de inquilino en un token. Este enfoque permite a la aplicación inspeccionar la notificación y comprobar que los usuarios trabajan con el inquilino al que se les permite acceder. Si usa el modelo de seguridad basado en roles, puede extender el token para incluir información sobre el rol del usuario dentro de la entidad.

Sin embargo, si un solo usuario puede acceder a varios inquilinos, es posible que necesite una manera de que los usuarios indiquen con qué inquilino planea trabajar durante el proceso de inicio de sesión. Después de que el usuario seleccione su arrendatario activo, el IdP puede emitir un token que incluya el reclamo correcto del identificador del arrendatario y el rol para ese arrendatario. También debe tener en cuenta cómo los usuarios pueden alternar entre inquilinos, lo que requiere emitir un nuevo token.

Autorización basada en aplicaciones

Un enfoque alternativo consiste en hacer que el sistema de identidad sea independiente de los identificadores y roles de inquilino. Los usuarios se identifican a través de sus credenciales o una relación de federación, y los tokens no incluyen una reclamación de identificador de inquilino. Una lista o base de datos independiente mantiene registros de qué usuarios tienen acceso a cada arrendatario. A continuación, el nivel de aplicación comprueba si un usuario especificado está autorizado para acceder a los datos de un inquilino específico en función de esa lista.

Uso de Microsoft Entra ID o Id. externo

Microsoft Entra ID y External ID son plataformas de identidad administrada que puede usar en su propia solución multiinquilino.

Muchas soluciones multiinquilino funcionan como SaaS. La elección de usar Microsoft Entra ID o el ID externo depende en parte de cómo defina sus tenants (inquilinos) o su base de clientes.

Importante

Azure AD B2C también admite muchos de los escenarios de este artículo. Sin embargo, a partir del 1 de mayo de 2025, ya no está disponible para la compra por nuevos clientes, por lo que no se recomienda para soluciones nuevas. Para más información, consulte Preguntas más frecuentes sobre Azure AD B2C.

Antipatrones que se deben evitar

Construcción o gestión de su propio sistema de identidad

La construcción de una plataforma de identidad moderna es compleja. Requiere compatibilidad con diversos protocolos y estándares, y una implementación incorrecta puede introducir vulnerabilidades de seguridad. Dado que los estándares y los protocolos cambian, debe actualizar continuamente el sistema de identidades para mitigar los ataques e incorporar las características de seguridad más recientes. También es importante asegurarse de que un sistema de identidad sea resistente porque cualquier tiempo de inactividad puede tener consecuencias graves para el resto de la solución. En la mayoría de los escenarios, la implementación de un IdP no beneficia directamente a la empresa, pero es necesario implementar un servicio multiinquilino. Es mejor usar un sistema de identidad especializado que los expertos crean, operan y protegen.

Al ejecutar un sistema de identidad propio, es necesario almacenar hashes de contraseña u otras formas de credenciales que se convierten en un objetivo tentador para los atacantes. Incluso el hasheo y salado de contraseñas suele ser una protección insuficiente porque los atacantes tienen suficiente capacidad de cálculo para comprometer estas credenciales.

Cuando gestionas un sistema de identidades, eres responsable de generar y distribuir códigos de autenticación multifactor (MFA) o contraseñas de un solo uso. Necesita un mecanismo para enviar estos códigos a través de SMS o correo electrónico. También es responsable de detectar ataques dirigidos y por fuerza bruta, limitar los intentos de inicio de sesión y mantener los registros de auditoría.

En lugar de compilar o administrar su propio sistema de identidad, es mejor usar un servicio o componente precompilado. Por ejemplo, considere la posibilidad de usar plataformas de identidad administrada como Microsoft Entra ID o External ID. Los proveedores de estas plataformas son responsables de operar la infraestructura y normalmente garantizan la compatibilidad con los estándares actuales de identidad y autenticación.

No tener en cuenta los requisitos de los inquilinos

Los inquilinos suelen tener preferencias sólidas sobre cómo administrar la identidad en las soluciones que usan. Por ejemplo, muchos clientes empresariales requieren federación con sus propios IDP para habilitar el inicio de sesión único y evitar administrar varios conjuntos de credenciales. Otros inquilinos pueden requerir autenticación multifactorial (MFA) o medidas de seguridad adicionales para el proceso de inicio de sesión. Si no tiene en cuenta estos requisitos durante el diseño, agregarlos más adelante puede ser difícil.

Asegúrese de que comprende los requisitos de identidad de los inquilinos antes de finalizar el diseño del sistema de identidades. Para obtener más información sobre los requisitos específicos, consulte Consideraciones de arquitectura para la identidad en una solución multiinquilino.

Confusión entre usuarios e inquilinos

Es importante tener en cuenta claramente cómo define la solución a un usuario y a un inquilino. En muchos escenarios, la relación puede ser compleja. Por ejemplo, un inquilino podría contener varios usuarios y un único usuario podría unirse a varios inquilinos.

Asegúrese de que tiene un proceso claro para realizar un seguimiento del contexto del inquilino dentro de su aplicación y sus solicitudes. En algunos escenarios, este proceso requiere incluir un identificador de inquilino en cada token de acceso y validarlo en cada solicitud. En otros casos, la información de autorización del inquilino se almacena por separado de las identidades de usuario. Este enfoque requiere un sistema de autorización más complejo para administrar qué usuarios pueden realizar operaciones específicas dentro de cada inquilino.

El seguimiento del contexto de inquilino de un usuario o token es aplicable a cualquier modelo de arrendamiento porque una identidad de usuario siempre tiene un contexto de inquilino dentro de una solución multiinquilino. Se recomienda realizar un seguimiento del contexto del arrendatario al implementar stamps independientes para un único arrendatario, lo cual prepara el código base para el futuro en otras formas de multialojamiento.

Combinación de la autorización de roles y recursos

Es importante elegir un modelo de autorización que se adapte a la solución. La seguridad basada en roles es sencilla de implementar, pero la autorización basada en recursos proporciona un control más específico. Evalúe los requisitos de los inquilinos y determine si necesitan autorizar a algunos usuarios a acceder solo a partes específicas de la solución.

No escribir los registros de auditoría

Los registros de auditoría son una herramienta importante para comprender su entorno y cómo implementan el sistema los usuarios. Al auditar todos los eventos relacionados con la identidad, a menudo puede determinar si su sistema de identidad está siendo atacado, y puede revisar cómo se está utilizando el sistema. Asegúrese de escribir y almacenar registros de auditoría en el sistema de identidades. Considere si los registros de auditoría de identidad de su solución deben estar disponibles para que los inquilinos los revisen.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales

Otros colaboradores:

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