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

Cada vez que llega una solicitud a la aplicación, debe determinar el inquilino para el que está pensada 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 a continuación:

En esta página, ofrecemos una guía para los responsables de la toma de decisiones técnicas sobre los enfoques que pueden tener en cuenta para asignar las solicitudes al inquilino adecuado, así como las contrapartidas de los enfoques.

Enfoques para identificar inquilinos

Hay varias maneras de identificar el inquilino para una solicitud entrante.

Nombres de dominio

Si usa nombres de dominio o subdominio específicos del inquilino, es probable que las solicitudes se puedan asignar fácilmente a los inquilinos mediante el encabezado Host 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 es así, ¿cómo identificarán los usuarios el inquilino al que necesitan acceder?
• ¿Qué otra información usa para comprobar el acceso al inquilino? Por ejemplo, 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. Se puede comunicar mediante lo siguiente:

• 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 al inquilino correcto mediante la adición de 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 es así, ¿cómo identificará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 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 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 los inquilinos con los que les gustaría trabajar?
• ¿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 y se pueden usar para buscar el inquilino.

Las claves de API se pueden generar de varias maneras. Un enfoque común es generar un valor criptográfico aleatorio y almacenarlo en una tabla de búsqueda, junto con el id. 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. Otro enfoque es crear una cadena con significado con un id. de inquilino incluido en ella y, a continuación, firmar 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?
• ¿El mero hecho de confiar en las claves de API rotadas por el cliente proporciona un nivel adecuado de seguridad para las API?

Certificados de cliente

La autenticación de certificados de cliente, a veces denominada TLS mutuo (mTLS), se usa normalmente para la comunicación entre servicios. Los certificados de cliente proporcionan una manera segura de autenticar a los clientes. De forma similar a los tokens y las notificaciones, los certificados de cliente proporcionan atributos que se pueden usar para determinar el inquilino. 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 lo siguiente:

• ¿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.
• ¿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?

Proxies 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 los tokens.

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.
• 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.
• 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 se usa OAuth 2.0, se realiza la validación mediante la inspección de las notificaciones de audiencia y ámbito.

Al implementar la validación de solicitudes, debe tener en cuenta lo siguiente:

• ¿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.

Rendimiento

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.

Afinidad de sesión

Un enfoque para reducir la sobrecarga del rendimiento de la lógica de asignación de inquilinos es usar la afinidad 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 la afinidad de sesión para reducir la sobrecarga de las solicitudes de asignación a inquilinos?
• ¿Qué servicios usa para enrutar las solicitudes a las implementaciones físicas de cada inquilino? ¿Admiten estos servicios la afinidad de sesión basada en cookies?

Migración de inquilino

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 suceda, tenga en cuenta que el proceso de asignación de inquilinos debe actualizarse. Puede que deba considerar lo siguiente:

• 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 de las entradas DNS en el 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.

Colaboradores

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
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, 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.