Consideraciones de arquitectura para la identidad en una solución multiinquilino

La identidad es un aspecto importante de cualquier solución multiinquilino. Los componentes de identidad de la aplicación son responsables de las siguientes tareas:

• Comprobación de la identidad de un usuario, conocida como autenticación

• Aplicar los permisos de un usuario dentro del ámbito de un inquilino, conocido como autorización.

Es posible que los clientes también deseen autorizar a las aplicaciones externas a acceder a sus datos o integrarlos con la solución. La identidad de un usuario determina a qué información puede acceder un usuario o servicio. Es importante que tenga en cuenta sus requisitos de identidad para aislar la aplicación y los datos entre inquilinos.

Antes de definir una estrategia de identidad multiinquilino, considere primero los siguientes requisitos de identidad de alto nivel para el servicio:

• Determine si los usuarios o las identidades de carga de trabajo acceden a una sola aplicación o a varias aplicaciones dentro de una familia de productos. Algunas familias de productos pueden incluir aplicaciones distintas que comparten la misma infraestructura de identidad, como sistemas de punto de venta y plataformas de administración de inventario.

• Considere si la solución implementa estándares de autenticación y autorización modernos, como OAuth2 y OpenID Connect.

• Evalúe si la autenticación está limitada a las aplicaciones basadas en la interfaz de usuario o si el acceso a la API también se aplica a los inquilinos y a los sistemas de terceros.

• Determine si los inquilinos deben federarse con sus propios IdP y si se deben admitir varios IdP para cada inquilino. Por ejemplo, puede tener inquilinos con el identificador de Entra de Microsoft, Auth0 y los servicios de federación de Active Directory en los que cada inquilino se federa con la solución. Identifique qué protocolos de federación utilizan sus IdP, ya que esos protocolos determinan qué debe admitir su IdP.

• Revise los requisitos de cumplimiento aplicables que necesiten cumplir, como el Reglamento general de protección de datos (RGPD), que dan forma a su estrategia de identidad.

• Determine si los inquilinos requieren que los datos de identidad se almacenen en regiones geográficas específicas para satisfacer las necesidades legales, de cumplimiento o operativas.

• Evalúe si los usuarios acceden a datos desde varios inquilinos dentro de la aplicación. Si lo hacen, es posible que tenga que admitir el cambio de arrendatario sin interrupciones o proporcionar vistas consolidadas entre arrendatarios para usuarios específicos. Por ejemplo, los usuarios que inician sesión en Azure Portal pueden cambiar fácilmente entre distintos directorios de identificador de Microsoft Entra y suscripciones a los que tienen acceso.

Al establecer los requisitos de alto nivel, puede empezar a planear detalles y requisitos más específicos, como orígenes de directorio de usuario y flujos de registro e inicio de sesión.

Directorio de identidades

Para que una solución multiinquilino autentique y autorice a un usuario o servicio, necesita un lugar para almacenar información de identidad. Un directorio puede incluir registros autoritativos para cada identidad. O puede contener referencias a identidades externas almacenadas en el directorio de otro IdP.

Al diseñar un sistema de identidades para su solución multiinquilino, debe tener en cuenta cuáles de los siguientes tipos de IdP podrían necesitar los inquilinos y los clientes:

• IdP local: Un IdP local permite a los usuarios registrarse en el servicio. Los usuarios proporcionan un nombre de usuario, una dirección de correo electrónico o un identificador, como un número de tarjeta de puntos. También proporcionan una credencial, como una contraseña. El IdP almacena tanto el identificador de usuario como las credenciales.

• IdP social: Un IdP social permite a los usuarios usar una identidad que tengan en una red social u otro IdP público, como Facebook, Google o una cuenta personal de Microsoft. Los IDP sociales se usan normalmente en soluciones SaaS de negocio a consumidor (B2C).

• Directorio de Microsoft Entra ID del tenante: En muchas soluciones SaaS de negocio a negocio (B2B), es posible que los tenantes ya tengan su propio directorio de Microsoft Entra ID y que quieran que su solución use su directorio como IdP para acceder a su solución. Este enfoque es posible cuando la solución se desarrolla como una aplicación multiinquilino de Microsoft Entra.

• Federación con el IdP de un inquilino: En algunas soluciones SaaS de B2B, es posible que los inquilinos tengan su propio IdP, que no sea el identificador de Entra de Microsoft y que quieran que la solución se federe con ella. La federación permite el inicio de sesión único (SSO). También permite a los inquilinos administrar el ciclo de vida y las directivas de seguridad de sus usuarios independientemente de la solución.

Debe tener en cuenta si los inquilinos necesitan admitir varios IdP. Por ejemplo, un solo inquilino podría necesitar admitir identidades locales, identidades sociales e identidades federadas. Este requisito es típico cuando las empresas usan una solución diseñada para sus empleados y contratistas. Pueden usar la federación para conceder acceso a los empleados, al tiempo que también permiten el acceso a contratistas o usuarios que no tienen cuentas en el IdP federado.

Almacenamiento de la información de autenticación y autorización de inquilinos

En una solución multiinquilino, debe tener en cuenta dónde almacenar los distintos tipos de información de identidad, incluidos los siguientes:

• Detalles sobre las cuentas de usuario y servicio, incluidos sus nombres y otra información que requieren los inquilinos.

• Información necesaria para autenticar de forma segura a los usuarios, incluida la información para la autenticación multifactor (MFA).

• Información específica del arrendatario, como roles y permisos del arrendatario, para la autorización.

Tenga en cuenta las siguientes opciones para almacenar información de identidad:

• Almacene toda la información de identidad y autorización en el directorio IdP y compártala entre varios inquilinos.

• Almacene las credenciales de usuario en el directorio IdP. Almacene los datos de autorización en el nivel de aplicación, junto con la información del inquilino.

Determinación del número de identidades de un usuario

Las soluciones multicliente suelen permitir que un usuario o una identidad de carga de trabajo acceda a los recursos y datos de aplicaciones en múltiples clientes. Cuando se requiera este enfoque, tenga en cuenta los siguientes factores:

• Decida si va a crear una identidad de usuario única para cada persona o decídase por crear identidades separadas para cada combinación de usuario y tenant.

  • Use una sola identidad para cada persona siempre que sea posible. Simplifica la administración de cuentas para el proveedor de soluciones y los usuarios. Además, muchas de las protecciones de amenazas inteligentes que proporcionan los IdP modernos dependen de cada persona que tenga una sola cuenta de usuario.

  • Use varias identidades distintas en algunos escenarios. Por ejemplo, si los usuarios usan su sistema para fines profesionales y personales, es posible que quieran separar sus cuentas de usuario. O bien, si los inquilinos tienen estrictos requisitos de almacenamiento de datos geográficos o normativos, es posible que requieran que una persona tenga varias identidades para que puedan cumplir las normativas o las leyes.

• Evite almacenar credenciales varias veces si usa identidades por inquilino. Los usuarios deben tener sus credenciales almacenadas en una sola identidad y debe usar características como las identidades de invitado para hacer referencia a las mismas credenciales de usuario desde los registros de identidad de varios inquilinos.

Conceder a los usuarios acceso a los datos de inquilino

Tenga en cuenta cómo planea asignar usuarios a un inquilino. Por ejemplo, durante el proceso de registro, puede proporcionar un código de invitación único que los usuarios introducirán la primera vez que accedan a un inquilino. En algunas soluciones, el nombre de dominio de la dirección de correo electrónico de registro del usuario puede identificar su inquilino asociado. Como alternativa, puede usar otro atributo del registro de identidad del usuario para determinar la asignación de inquilinos. A continuación, esta asociación debe almacenarse en función de identificadores únicos inmutables para el inquilino y el usuario.

Si la solución limita cada usuario a acceder a los datos de un solo inquilino, tenga en cuenta las siguientes decisiones:

• Determine cómo detecta el IdP a qué inquilino accede un usuario.

• Explicar cómo el IdP comunica el identificador de inquilino a la aplicación. Normalmente, se agrega una declaración de identificador de inquilino al token.

Si es necesario conceder acceso a un solo usuario a varios inquilinos, tenga en cuenta las siguientes decisiones:

• La solución debe admitir la lógica para identificar a los usuarios y conceder los permisos adecuados en todos los inquilinos. Por ejemplo, un usuario podría tener derechos administrativos en un inquilino, pero un acceso limitado en otro inquilino. Por ejemplo, supongamos que un usuario se registró con una identidad social y se le concede acceso a dos inquilinos. El inquilino A enriqueció la identidad del usuario con más información. ¿El inquilino B debería tener acceso a la información enriquecida?

• Un mecanismo claro debe permitir que los usuarios cambien entre inquilinos. Este enfoque garantiza una experiencia de usuario fluida y evita el acceso accidental entre inquilinos.

• Las identidades de carga de trabajo, si las usa, deben especificar a qué inquilino intentan acceder. Este requisito puede incluir la inserción de contexto específico del inquilino en las solicitudes de autenticación.

• Considere si la información específica del inquilino almacenada en el registro de identidad de un usuario podría filtrar accidentalmente entre inquilinos. Por ejemplo, si un usuario se registra con una identidad social y obtiene acceso a dos inquilinos, y el inquilino A enriquece el perfil de usuario, determine si el inquilino B debe tener acceso a esa información enriquecida.

Proceso de registro de usuario para identidades locales o identidades sociales

Es posible que algunos inquilinos necesiten permitir que los usuarios se registren para obtener una identidad en su solución. El registro de autoservicio puede ser necesario si no se requiere la federación con el IdP del inquilino. Si se necesita un proceso de registro automático, debe tener en cuenta los siguientes factores:

• Defina los orígenes de identidad desde los que los usuarios pueden registrarse. Por ejemplo, determine si los usuarios pueden crear una identidad local y también usar un IdP social.

• Especifique si la solución solo permite dominios de correo electrónico específicos si se usan identidades locales. Por ejemplo, determine si un inquilino puede restringir los registros a los usuarios con una @contoso.com dirección de correo electrónico.

• El nombre principal de usuario (UPN) que se usa para identificar identidades locales debe establecerse claramente. Los UPN comunes incluyen direcciones de correo electrónico, nombres de usuario, números de teléfono o identificadores de pertenencia. Dado que los UPN pueden cambiar, es aconsejable hacer referencia al identificador único inmutable subyacente para la autorización y la auditoría. Un ejemplo es el identificador de objeto (OID) de Microsoft Entra ID.

• Es posible que se requiera la comprobación de los UPN para garantizar su precisión. Este proceso podría incluir validar la propiedad de una dirección de correo electrónico o un número de teléfono antes de conceder acceso.

• Algunas soluciones pueden requerir que los administradores de inquilinos aprueben los registros de usuario. Este proceso de aprobación permite el control administrativo sobre quién se une a un inquilino.

• Decida si los inquilinos necesitan una experiencia de registro o una URL específica para el inquilino. Por ejemplo, antes de continuar determine si los inquilinos requieren una experiencia de registro con marca cuando se registran o la capacidad de interceptar una solicitud de registro y realizar una validación adicional.

Acceso al inquilino para usuarios de registro de autoservicio

Si los usuarios pueden registrarse para obtener una identidad, defina un proceso para concederles acceso a un inquilino. El flujo de registro puede incluir un proceso de concesión de acceso manual o un proceso automatizado en función de la información sobre los usuarios, como sus direcciones de correo electrónico. Es importante planear este proceso y tener en cuenta los siguientes factores:

• Defina cómo el flujo de registro determina que a un usuario se le conceda acceso a una entidad específica.

• Defina si la solución revoca automáticamente el acceso de usuario a un inquilino cuando corresponda. Por ejemplo, cuando los usuarios abandonan una organización, debe haber un proceso manual o automatizado para quitar su acceso.

• Proporcione una funcionalidad de auditoría de usuario para que los inquilinos puedan revisar qué usuarios tienen acceso a su entorno y comprender sus permisos asignados.

Administración automatizada del ciclo de vida de la cuenta

Un requisito común para los clientes corporativos o empresariales de una solución es un conjunto de características que les permite automatizar la incorporación y retirada de cuentas. Los protocolos abiertos, como System for Cross-Domain Identity Management (SCIM), proporcionan un enfoque estándar del sector para la automatización. Este proceso automatizado suele incluir la creación y eliminación de registros de identidad y la administración de permisos de inquilino. Tenga en cuenta los siguientes factores al implementar la administración automatizada del ciclo de vida de la cuenta en una solución multiinquilino:

• Determine si los clientes necesitan configurar y administrar un proceso de ciclo de vida automatizado para cada inquilino. Por ejemplo, cuando se incorpora un usuario, es posible que tenga que crear la identidad en varios inquilinos de su aplicación, donde cada inquilino tiene un conjunto diferente de permisos.

• Determine si necesita implementar SCIM o ofrecer federación. La federación permite a los clientes conservar el control sobre la gestión de usuarios manteniendo la fuente de veracidad dentro de sus propios sistemas, en lugar de gestionar usuarios locales en su solución.

Proceso de autenticación del usuario

Cuando un usuario inicia sesión en una aplicación multiinquilino, su sistema de identidad autentica al usuario. Tenga en cuenta los siguientes factores al planear el proceso de autenticación:

• Algunos inquilinos pueden requerir la capacidad de configurar sus propias directivas de MFA. Por ejemplo, si sus inquilinos están en el sector de servicios financieros, deben implementar directivas de MFA estrictas, mientras que un pequeño comercio en línea podría no tener los mismos requisitos.

• La opción para definir reglas de acceso condicional personalizadas podría ser importante para los inquilinos. Por ejemplo, es posible que los distintos inquilinos necesiten bloquear los intentos de inicio de sesión desde regiones geográficas específicas.

• Determine si los inquilinos necesitan personalizar el proceso de inicio de sesión individualmente. Por ejemplo, es posible que la solución tenga que mostrar el logotipo de un cliente. O es posible que tenga que recuperar información de usuario, como un número de recompensas, de otro sistema y devolverla al IdP para enriquecer el perfil de usuario.

• Es posible que algunos usuarios necesiten suplantar a otros usuarios. Por ejemplo, un miembro del equipo de soporte técnico podría querer investigar un problema que otro usuario tiene suplantando su cuenta de usuario sin tener que autenticarse como usuario.

• Es posible que se requiera acceso a la API para algunos usuarios o aplicaciones externas. Estos escenarios pueden incluir llamar directamente a las API de la solución, lo que omite los flujos de autenticación de usuario estándar.

Identidades de carga de trabajo

En la mayoría de las soluciones, una identidad suele representar a un usuario. Algunos sistemas multiinquilino también permiten que los servicios y las aplicaciones usen identidades de carga de trabajo para obtener acceso a los recursos de la aplicación. Por ejemplo, es posible que los inquilinos necesiten acceder a una API que proporciona la solución para que puedan automatizar sus tareas de administración.

Microsoft Entra admite identidades de carga de trabajo y otros idP también los admiten normalmente.

Las identidades de carga de trabajo son similares a las identidades de usuario, pero normalmente requieren métodos de autenticación diferentes, como claves o certificados. Las identidades de carga de trabajo no usan MFA. En su lugar, las identidades de carga de trabajo suelen requerir otros controles de seguridad, como la renovación periódica de las claves y la caducidad de los certificados.

Si sus clientes pueden activar el acceso mediante identidad de trabajo a su solución de multiinquilino, debe tener en cuenta los siguientes factores:

• Determine cómo se crean y administran las identidades de carga de trabajo en cada inquilino.

• Decida cómo se limitan las solicitudes de identidad de carga de trabajo en el inquilino.

• Evalúe si necesita limitar el número de identidades de carga de trabajo que crea cada inquilino.

• Determine si se requieren controles de acceso condicional para las identidades de carga de trabajo de cada inquilino. Por ejemplo, un inquilino podría querer limitar la autenticación de una identidad de carga de trabajo desde fuera de una región específica.

• Identifique qué controles de seguridad proporciona a los inquilinos para asegurarse de que las identidades de carga de trabajo permanecen seguras. Por ejemplo, la rotación automatizada de claves, expiración de claves, la expiración de certificados y la supervisión de riesgos de inicio de sesión ayudan a reducir el riesgo de uso indebido de la identidad de la carga de trabajo.

Establecer una federación con un IdP para SSO

Los inquilinos que ya tienen sus propios directorios de usuario pueden querer que su solución se federe en sus directorios. La federación permite que la solución use las identidades de su directorio en lugar de administrar otro directorio con identidades distintas.

La federación es especialmente importante cuando algunos inquilinos quieren especificar sus propias directivas de identidad o para habilitar experiencias de SSO.

Si espera que los inquilinos se federen con la solución, tenga en cuenta los siguientes factores:

• Considere el proceso para configurar la federación de un inquilino. Determine si los inquilinos configuran la federación por sí mismos o si el proceso requiere la configuración manual y el mantenimiento por parte del equipo.

• Defina qué protocolos de federación admite la solución.

• Establezca procesos que impidan que las configuraciones incorrectas de federación concedan acceso a inquilinos no deseados.

• Planee si el IdP de un solo inquilino debe estar federado a más de un inquilino de la solución. Por ejemplo, si los clientes tienen un inquilino de entrenamiento y de producción, es posible que necesiten federar el mismo IdP con cada inquilino.

Modelos de autorización

Decida el modelo de autorización que tenga más sentido para su solución. Tenga en cuenta los siguientes enfoques de autorización comunes:

• Autorización basada en roles: Los usuarios se asignan a roles. Algunas características de la aplicación están restringidas a roles específicos. Por ejemplo, un usuario con rol de administrador puede realizar cualquier acción, mientras que un usuario con un rol inferior podría tener un subconjunto de permisos en el sistema.

• Autorización basada en recursos: La solución proporciona un conjunto de recursos distintos, cada uno de los cuales tiene su propio conjunto de permisos. Un usuario específico podría ser un administrador de un recurso y no tener acceso a otro recurso.

Estos modelos son distintos y el enfoque que seleccione afecta a la implementación y a la complejidad de las directivas de autorización que puede implementar.

Derechos y licencias

En algunas soluciones puede usar licencias por usuario como parte del modelo de precios comerciales. En este escenario, se proporcionan distintos niveles de licencias de usuario que tienen distintas funcionalidades. Por ejemplo, los usuarios con una licencia podrían usar un subconjunto de las características de la aplicación. Las funcionalidades a las que pueden acceder usuarios específicos, en función de sus licencias, a veces se denominan derechos.

Se recomienda realizar un seguimiento y aplicar derechos en el código de aplicación o en un sistema de derechos dedicados, en lugar de confiar en el sistema de identidades. Este proceso es similar a la autorización, pero se produce fuera del nivel de administración de identidades.

Hay varias razones para esta separación:

• Complejidad de los modelos de licencias: Las reglas de licencias suelen ser complejas y específicas del modelo de negocio. Por ejemplo, las licencias pueden ser por puesto, basadas en el tiempo (asignación diaria o mensual), limitar el uso simultáneo o tener reglas de reasignación específicas. Por lo general, los proveedores de identidades están diseñados para la autenticación de usuarios y la autorización básica, no para la lógica compleja de licencias comerciales.

• Independencia: Confiar en las características del proveedor de identidades para la gestión de licencias puede restringir tu solución a dicho proveedor y sus limitaciones. Si admite a clientes que usan diferentes proveedores de identidad, tendría que crear una solución a medida para ellos de todos modos.

Un patrón común es administrar licencias dentro de la base de datos de la aplicación o un servicio dedicado. Cuando un usuario inicia sesión, el proveedor de identidades recupera sus atribuciones y los inserta en el token de autorización como reclamos personalizados que los componentes de la aplicación pueden verificar en tiempo de ejecución.

Escala de identidades y volumen de autenticación

A medida que crecen las soluciones multiinquilino, aumenta el número de usuarios e solicitudes de inicio de sesión que la solución necesita procesar. Evalúe estas consideraciones de escalabilidad:

• Evalúe si el directorio de usuario se escala para admitir el número necesario de usuarios.

• Evalúe si el proceso de autenticación controla el número esperado de inicios de sesión y registros.

• Determine si hay picos que el sistema de autenticación no puede controlar. Por ejemplo, a las 9:00 horas del Pacífico, todos los usuarios de la región oeste de Estados Unidos podrían empezar a trabajar e iniciar sesión en la solución, lo que crea un pico en las solicitudes de inicio de sesión. Estos escenarios a veces se denominan tormentas de inicio de sesión.

• Determine si la carga alta en partes de la solución afecta al rendimiento del proceso de autenticación. Por ejemplo, si la autenticación requiere llamar a una API de nivel de aplicación, un aumento en las solicitudes de autenticación podría afectar al rendimiento general del sistema.

• Defina cómo se comporta la solución si el IdP deja de estar disponible. Considere si se debe incluir un servicio de autenticación de copia de seguridad para mantener la continuidad empresarial.

Colaboradores

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

Autores principales:

• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Otros colaboradores:

• Jelle Druyts | Ingeniero de clientes principal, FastTrack for Azure
• Landon Pierce | Ingeniero sénior de clientes
• Sander van den Hoven | Creador sénior de estrategias de tecnología de asociados
• Nick Ward | Arquitecto sénior de soluciones en la nube

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

Recurso relacionado

• Enfoques arquitectónicos para la identidad en soluciones multiinquilino