Asignación de solicitudes a tenants en una solución multiinquilino

Cada vez que llega una solicitud a la aplicación, debe determinar el contexto de inquilino, que es el inquilino que realiza la solicitud. Si tiene una infraestructura específica de inquilino que se puede hospedar en regiones geográficas diferentes, debe hacer coincidir la solicitud entrante con un inquilino. A continuación, debe reenviar la solicitud a la infraestructura física que hospeda los recursos de ese inquilino, como se muestra en el diagrama siguiente:

Muchas aplicaciones multitenant también cuentan con permisos basados en el usuario. El mapeo de tenants es una actividad independiente. Es necesario conocer tanto al usuario que realiza la solicitud como al tenant en el que está trabajando.

En este artículo se proporcionan instrucciones para los responsables de la toma de decisiones técnicas sobre los enfoques que puede considerar para asignar solicitudes al tenant adecuado y las compensaciones que implican los enfoques.

Enfoques para identificar inquilinos

Hay varias maneras de identificar el tenant para una solicitud entrante. Cada enfoque requiere inspeccionar algún aspecto de la solicitud entrante.

Nombres de dominio

Si utilizas nombres de dominio o subdominio específicos de cada tenant, es probable que las solicitudes puedan asignarse fácilmente a los tenants utilizando el encabezado Host, el encabezado X-Forwarded-Host u otro encabezado HTTP que incluya el nombre de host original de cada solicitud.

Sin embargo, tenga en cuenta las preguntas siguientes:

• ¿Cómo sabrán los usuarios qué nombre de dominio usar para acceder al servicio?
• ¿Tiene un punto de entrada central, como una página de destino o una página de inicio de sesión, que usen todos los tenants? Si lo hace, ¿cómo seleccionarán los usuarios el tenant con el que trabajan?
• ¿Qué otra información usa para comprobar el acceso a los recursos del tenant, como los tokens de autorización? ¿Incluyen los tokens de autorización los nombres de dominio específicos del inquilino?

Propiedades de la solicitud HTTP

Si no usa nombres de dominio específicos del tenant, puede que todavía pueda usar aspectos de la solicitud HTTP para identificar el tenant al que se dirige una solicitud determinada. Por ejemplo, considere una solicitud HTTP que identifica el nombre de inquilino como tailwindtraders. Esto puede comunicarse mediante uno de los métodos siguientes:

• La estructura de la ruta de acceso URL, como https://app.contoso.com/tailwindtraders/.
• Una cadena de consulta en la dirección URL, como https://contoso.com/app?tenant=tailwindtraders.
• Un encabezado de solicitud HTTP personalizado, como Tenant-Id: tailwindtraders.

Al usar este enfoque, debe tener en cuenta las siguientes preguntas:

• ¿Sabrán los usuarios cómo acceder al servicio? Por ejemplo, si usa una cadena de consulta para identificar tenants, ¿será necesario que una página de aterrizaje central dirija a los usuarios a la página correcta del tenant agregando la cadena de consulta?
• ¿Tiene un punto de entrada central, como una página de aterrizaje o una página de inicio de sesión, que usen todos los inquilinos? Si lo hace, ¿cómo seleccionarán los usuarios el tenant al que necesitan acceder?
• ¿Su aplicación proporciona API? Por ejemplo, ¿es la aplicación web una aplicación de página única (SPA) o una aplicación para dispositivos móviles con un back-end de API? Si es así, es posible que pueda usar una puerta de enlace de API o un proxy inverso para realizar la asignación de inquilinos.

Notificaciones de token

Muchas aplicaciones usan protocolos de autenticación y autorización basados en notificaciones, como OAuth 2.0 o SAML. Estos protocolos proporcionan tokens de autorización al cliente. Un token contiene un conjunto de notificaciones, que son fragmentos de información sobre la aplicación cliente o el usuario. Las notificaciones se pueden usar para comunicar información, como la dirección de correo electrónico de un usuario. Después, el sistema puede incluir la dirección de correo electrónico del usuario, buscar la asignación de usuario a tenant y reenviar la solicitud al despliegue adecuado. O incluso puede incluir la asignación de inquilinos en el sistema de identidades y agregar una notificación de id. de inquilino al token.

Si usa notificaciones para asignar solicitudes a inquilinos, debe tener en cuenta las siguientes preguntas:

• ¿Usará una notificación para identificar al inquilino? ¿Qué notificación usará?
• ¿Puede un usuario ser miembro de varios tenants? Si esto es posible, ¿cómo seleccionarán los usuarios el tenant con el que deseen trabajar para una solicitud específica?
• ¿Hay un sistema central de autenticación y autorización para todos los tenants? Si no es así, ¿cómo se asegurará de que todas las autoridades de token emitan notificaciones y tokens coherentes?

claves de API

Muchas aplicaciones exponen las API. Pueden ser para uso interno dentro de su organización o para uso externo por parte de los asociados o clientes. Un método común de autenticación para las API es usar una clave de API. Las claves de API se proporcionan con cada solicitud. Si registra el ID de inquilino para el que se emitió una clave, podrá consultar dicho ID cuando se utilice la clave.

Las claves de API se pueden generar de varias maneras. Estos son dos enfoques comunes:

• Genere un valor aleatorio criptográfico y almacénelo en una tabla de búsqueda, junto con el ID del tenant. Cuando se recibe una solicitud, el sistema busca la clave de API en la tabla de búsqueda y, a continuación, la empareja con un identificador de tenant.
• Cree una cadena significativa con un ID de inquilino incluido en ella. Firme digitalmente la clave mediante un enfoque como HMAC. Al procesar cada solicitud, se comprueba la firma y, a continuación, se extrae el id. de inquilino.

Pregúntese lo siguiente:

• ¿Cómo generará y emitirá claves de API?
• ¿Cómo recibirán y almacenarán de forma segura los clientes de API la clave de API?
• ¿Necesita que las claves de API expiren después de un período de tiempo? ¿Cómo puede rotar las claves de API de sus clientes sin provocar tiempo de inactividad?
• ¿Las claves de API generadas por el cliente proporcionan un nivel adecuado de seguridad para las API?

Certificados de cliente

La autenticación de certificados de cliente, a veces denominada TLS mutua (mTLS), se usa normalmente para la comunicación entre servicios y para dispositivos desatendidos o quioscos usados por usuarios no autenticados. Los certificados de cliente proporcionan una manera segura de autenticar a los clientes. Al igual que los tokens y las reclamaciones, los certificados de cliente proporcionan atributos que se pueden usar para determinar el arrendatario. Por ejemplo, el asunto del certificado puede contener la dirección de correo electrónico del usuario, que se puede usar para buscar el inquilino.

Al planear el uso de certificados de cliente para la asignación de inquilinos, tenga en cuenta los siguientes factores:

• ¿Cómo emitirá y renovará de forma segura los certificados de cliente en los que confía su servicio? Puede ser complejo trabajar con los certificados de cliente, ya que requieren una infraestructura especial para administrar y emitir los certificados. Si se controla incorrectamente, estas complejidades pueden reducir la seguridad en lugar de aumentarla.
• ¿Se usarán los certificados de cliente solo para las solicitudes de inicio de sesión iniciales o se adjuntarán a todas las solicitudes para el servicio?
• ¿Se volverá no administrable el proceso de emisión y administración de certificados cuando tenga un gran número de clientes?
• ¿Cómo implementará la asignación entre el certificado de cliente y el tenant?

Servidores proxy inversos

Un proxy inverso, también denominado proxy de aplicación, se puede usar para enrutar las solicitudes HTTP. Un proxy inverso acepta una solicitud de un punto de conexión de entrada y puede reenviar la solicitud a uno de los muchos puntos de conexión de back-end. Los proxies inversos son útiles para las aplicaciones multiinquilino, ya que pueden realizar la asignación entre algún fragmento de información de solicitud, descargando la tarea de la infraestructura de la aplicación.

Muchos proxies inversos pueden usar las propiedades de una solicitud para tomar una decisión sobre el enrutamiento de inquilinos. Pueden inspeccionar el nombre de dominio de destino, la ruta de acceso URL, la cadena de consulta, los encabezados HTTP e incluso las declaraciones dentro de los tokens o partes del cuerpo de la solicitud.

En Azure, se usan los siguientes proxies inversos comunes:

• Azure Front Door es un equilibrador de carga global y un firewall de aplicaciones web. Usa la red perimetral global de Microsoft para crear aplicaciones web rápidas, seguras y muy escalables. Puede usar conjuntos de reglas para extraer identificadores de inquilino y colocarlos en otra parte de la solicitud.
• Azure Application Gateway es un equilibrador de carga de tráfico web administrado que se implementa en la misma región física que el servicio de back-end.
• Azure API Management está optimizado para el tráfico de API. Azure API Management proporciona un motor de directivas completo que proporciona una gran flexibilidad para extraer información del inquilino de las solicitudes.
• Las tecnologías comerciales y de código abierto (que usted mismo hospeda) incluyen nginx, Traefik y HAProxy.

Validación de solicitud

Es importante que la aplicación valide que las solicitudes que recibe estén autorizadas para el inquilino. Por ejemplo, si la aplicación usa un nombre de dominio personalizado para asignar solicitudes al inquilino, la aplicación debe comprobar que cada solicitud recibida esté autorizada para ese inquilino. Aunque la solicitud incluya un nombre de dominio u otro identificador del tenant, no significa que deba conceder acceso automáticamente. Cuando usas OAuth 2.0, realizas la validación inspeccionando las reclamaciones de audiencia y ámbito.

Al implementar la validación de solicitudes, tenga en cuenta los siguientes factores:

• ¿Cómo autorizarás todas las solicitudes a tu aplicación? Debe autorizar las solicitudes, independientemente del enfoque que use para asignarlas a la infraestructura física.
• Utilice middleware y marcos de autenticación y autorización de confianza, ampliamente utilizados y bien mantenidos, en lugar de implementar toda la lógica de validación usted mismo. Por ejemplo, no implemente usted mismo la lógica de validación de firmas de tokens ni bibliotecas criptográficas para certificados de cliente. En su lugar, use características de su plataforma de aplicaciones (o paquetes de confianza conocidos) que se han validado y probado.

Performance

Es probable que la lógica de asignación de tenant se ejecute en cada solicitud de su aplicación. Tenga en cuenta la forma en que se escalará el proceso de asignación de inquilinos a medida que crezca la solución. Por ejemplo, si consulta una tabla de base de datos como parte de la asignación de tenants, ¿admitirá la base de datos una gran cantidad de carga? Si la asignación de inquilinos requiere descifrar un token, ¿serán los requisitos de cálculo demasiado altos con el tiempo? Si el tráfico es bastante moderado, es probable que esto no afecte al rendimiento general. Sin embargo, cuando tenga una aplicación a gran escala, la sobrecarga implicada en esta asignación puede ser significativa.

Cookies de sesión

Un enfoque para reducir la sobrecarga de rendimiento de la lógica de asignación de inquilinos es usar cookies de sesión. En lugar de realizar la asignación en cada solicitud, considere la posibilidad de calcular la información solo en la primera solicitud de cada sesión. A continuación, la aplicación proporciona una cookie de sesión al cliente. El cliente vuelve a pasar la cookie de sesión al servicio con todas las solicitudes de cliente posteriores dentro de esa sesión.

Considere las siguientes preguntas:

• ¿Puede usar cookies de sesión para reducir la sobrecarga de asignar solicitudes a tenants?
• ¿Qué servicios usa para enrutar las solicitudes a las implementaciones físicas de cada tenant? ¿Estos servicios admiten sesiones basadas en cookies?

Migración de inquilinos

A menudo, los inquilinos deben moverse a una nueva infraestructura como parte del ciclo de vida del inquilino. Cuando un tenant se mueve a un nuevo despliegue, los puntos de conexión HTTP a los que acceden pueden cambiar. Cuando esto sucede, tenga en cuenta que el proceso de mapeo de tenants debe cambiar. Es posible que tenga que tener en cuenta los siguientes factores:

• Si la aplicación usa nombres de dominio para las solicitudes de mapeo, también podría requerir un cambio de DNS en el momento de la migración. El cambio de DNS puede tardar tiempo en propagarse a los clientes, en función del período de vida (TTL) de las entradas DNS de su servicio DNS.
• Si la migración cambia las direcciones de los puntos de conexión durante el proceso de migración, considere la posibilidad de redirigir temporalmente las solicitudes del tenant a una página de mantenimiento que se actualice automáticamente.

Contributors

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

Autor principal:

• Daniel Scott-Raynsford | Partner Technology Strategist

Otros colaboradores:

• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

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

Paso siguiente

Obtenga información sobre la identidad en una aplicación multicliente.