Asignación de solicitudes a inquilinos 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. Cuando tenga una infraestructura específica del cliente que se pueda hospedar en diferentes regiones geográficas, debe asignar la solicitud entrante a un cliente. 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 multiinquilino también tienen permisos basados en el usuario. La asignación de inquilinos es una actividad independiente. Debe conocer tanto el usuario que realiza la solicitud como el inquilino en el que trabajan.

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 inquilino adecuado y a las desventajas implicadas en los enfoques.

Enfoques para identificar inquilinos

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

Nombres de dominio

Si usa nombres de dominio o subdominios específicos del inquilino, es probable que las solicitudes se puedan asignar fácilmente a los inquilinos mediante el encabezado, el HostX-Forwarded-Host encabezado u otro encabezado HTTP que incluya el nombre de host original para 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 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 inquilino con el que trabajan?
• ¿Qué otra información usa para comprobar el acceso a los recursos del inquilino, como los tokens de autorización? ¿Incluyen los tokens de autorización los nombres de dominio específicos del inquilino?

Propiedades de solicitudes HTTP

Si no usa nombres de dominio específicos de inquilino, puede que todavía pueda usar aspectos de la solicitud HTTP para identificar el inquilino 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 inquilinos, ¿será necesario que una página de aterrizaje central dirija a los usuarios a la página correcta del inquilino 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 inquilino al que necesitan acceder?
• ¿Proporciona la aplicación las 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 utilizar un API gateway o un proxy inverso para realizar la asignación de clientes.

Declaraciones 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 inquilino y reenviar la solicitud a la implementación adecuada. 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 inquilinos? Si esto es posible, ¿cómo seleccionarán los usuarios el inquilino con el que desea trabajar para una solicitud específica?
• ¿Hay un sistema central de autenticación y autorización para todos los inquilinos? 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 identificador de inquilino para el que se emitió una clave, puede buscar el identificador de inquilino cuando se usa 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 identificador de inquilino. Cuando se recibe una solicitud, el sistema busca la clave de API en la tabla de búsqueda y, a continuación, la empareja a un id. de inquilino.
• Cree una cadena significativa con un identificador de inquilino incluido en él. 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 rotará las claves de API de los 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 de confianza para el 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 inquilino?

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 notificaciones dentro de 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 solicitudes

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 de inquilino, 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á todas las solicitudes para la 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 cree bibliotecas de criptografía de certificados de cliente o lógica de validación de firma de token. En su lugar, use características de la 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 inquilinos se ejecute en cada solicitud para la 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 inquilinos, ¿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.

Pregúntese lo siguiente:

• ¿Puede usar cookies de sesión para reducir la sobrecarga de asignar solicitudes a inquilinos?
• ¿Qué servicios usa para enrutar las solicitudes a las implementaciones físicas de cada inquilino? ¿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 inquilino se mueve a una nueva implementación, los puntos de conexión HTTP a los que acceden pueden cambiar. Cuando esto sucede, tenga en cuenta que el proceso de asignación de inquilinos 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 asignación, 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 del 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 inquilino 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.

Pasos siguientes

Obtenga información sobre las consideraciones al trabajar con nombres de dominio en una aplicación multiinquilino.