Compartir a través de

Convertir la aplicación de un solo inquilino en multiinquilino en el Microsoft Entra ID

  • Artículo

Si ofrece una aplicación de software como servicio (SaaS) a muchas organizaciones, puede configurar la aplicación para que acepte inicios de sesión de cualquier inquilino de Microsoft Entra convirtiéndola en multiinquilino. Los usuarios de cualquier inquilino de Microsoft Entra podrán iniciar sesión en su aplicación después de dar su consentimiento para usar su cuenta con su aplicación.

En el caso de las aplicaciones existentes con su propio sistema de cuentas (u otros inicios de sesión de otros proveedores de nube), debe agregar código de inicio de sesión a través de OAuth2, OpenID Connect o el Lenguaje de Marcado para Confirmaciones de Seguridad (SAML), y colocar un botón "Iniciar sesión con Microsoft" en la aplicación.

En esta guía paso a paso, llevará a cabo los cuatro pasos necesarios para convertir una aplicación de inquilino único en una aplicación multiinquilino de  Microsoft Entra:

  1. Actualizar el registro de aplicación para que sea multiempresa
  2. Actualización del código para enviar solicitudes al punto de conexión /common
  3. Actualice el código para administrar varios valores issuer.
  4. Comprenda el consentimiento de administrador y usuario y realice los cambios apropiados en el código.

Si quiere probar a usar uno de nuestros ejemplos, consulte Compilar una aplicación web SaaS multiinquilino que llama a Microsoft Graph con Microsoft Entra ID y OpenID Connect

Requisitos previos

Actualizar el registro para que sea multiempresa

De forma predeterminada, los registros de API y de aplicación web en Microsoft Entra son de un solo inquilino cuando se crean. Para que el registro sea multiinquilino, inicie sesión en el Centro de administración Microsoft Entra y seleccione el registro de aplicación que desea actualizar. Con el registro de aplicación abierto, seleccione el panel Autenticación y vaya a la sección Tipos de cuenta admitidos. Cambie la configuración a Cuentas en cualquier directorio organizativo.

Cuando se crea una aplicación de un solo inquilino en Centro de administración Microsoft Entra, uno de los elementos enumerados en la página Información general es el URI de id. de aplicación. Esta es una de las formas en que se identifica una aplicación en los mensajes de protocolo y se puede agregar en cualquier momento. El URI de id. de aplicación para las aplicaciones de inquilino único puede ser único globalmente dentro de ese inquilino. En cambio, para las aplicaciones multiinquilino, debe ser globalmente único en todos los inquilinos, lo que garantiza que Microsoft Entra ID puede encontrar la aplicación en todos los inquilinos.

Por ejemplo, si el nombre del inquilino era contoso.onmicrosoft.com, un URI de id. de aplicación válido sería https://contoso.onmicrosoft.com/myapp. Si el URI de id. de aplicación no sigue este patrón, la configuración de una aplicación como multiinquilino dará error.

Actualización del código para enviar solicitudes a /common

Con una aplicación multiinquilino, la aplicación no puede saber inmediatamente de qué inquilino procede el usuario, por lo que las solicitudes no se pueden enviar al punto de conexión de un inquilino. En su lugar, las solicitudes se envían a un punto de conexión común (https://login.microsoftonline.com/common) que sirve en todos los inquilinos de Microsoft Entra, que actúa como un centro central que controla las solicitudes.

Abra la aplicación en el IDE y edite el código y cambie el valor del id. de inquilino a /common. Este punto de conexión no es un inquilino ni un emisor. Cuando la Plataforma de identidad de Microsoft recibe una solicitud en el punto de conexión /common, inicia la sesión del usuario y detecta cuál es el inquilino del que procede. El punto de conexión funciona con todos los protocolos de autenticación compatibles con Microsoft Entra (OpenID Connect, OAuth 2.0, SAML 2.0 y WS-Federation).

La respuesta de inicio de sesión a la aplicación contiene un token que representa al usuario. El valor issuer del token indica a una aplicación el inquilino del que procede el usuario. Cuando el punto de conexión /common devuelva una respuesta, el valor issuer del token corresponderá al inquilino del usuario.

Nota:

Existen, en realidad, 2 autoridades para las aplicaciones multiinquilino:

  • https://login.microsoftonline.com/common para aplicaciones que procesan cuentas en cualquier directorio de la organización (cualquier directorio de Microsoft Entra) y cuentas personales de Microsoft (como Skype, XBox).
  • https://login.microsoftonline.com/organizations para las aplicaciones que procesan cuentas en cualquier directorio de la organización (cualquier directorio de Microsoft Entra):

Las explicaciones de este documento usan common. Pero puede reemplazarlo por organizations si su aplicación no es compatible con las cuentas personales de Microsoft.

Actualice el código para administrar varios valores issuer

Las aplicaciones web y las API web reciben y validan los tokens que provienen de la Plataforma de identidad de Microsoft. Las aplicaciones cliente nativas no validan los tokens de acceso y se deben tratar como opacos. En su lugar solicitan y reciben tokens de la Plataforma de identidad de Microsoft, lo hacen para enviarlos a las API, donde se validan.

Las aplicaciones multiinquilino deben realizar más comprobaciones al validar un token. Una aplicación multiinquilino está configurada para consumir metadatos de claves de URL de claves de /organizations o /common. La aplicación debe validar que la propiedad issuer en los metadatos publicados coincide con la notificación iss en los tokens, además de la comprobación habitual de que la notificación iss en los tokens contiene la notificación del id. del inquilino (tid). Para obtener más información, consulte Validar tokens.

Para que un usuario inicie sesión en una aplicación en Microsoft Entra, la aplicación debe estar representada en el inquilino del usuario. Esto permite que la organización realice cosas como aplicar directivas únicas cuando los usuarios de su inquilino inician sesión en la aplicación. En el caso de una aplicación de un solo inquilino, se puede usar el registro a través de Centro de administración Microsoft Entra.

Para una aplicación multiinquilino, el registro inicial de la aplicación reside en el inquilino de Microsoft Entra utilizado por el desarrollador. Cuando usuarios de otro inquilino inician sesión en la aplicación por primera vez,Microsoft Entra les pide que den su consentimiento a los permisos solicitados por ella. Si aceptan, se crea una representación de la aplicación llamada entidad de servicio en el inquilino del usuario, y el inicio de sesión puede continuar. También se crea una delegación en el directorio que registra el consentimiento del usuario a la aplicación. Para más información sobre los objetos Application y ServicePrincipal de la aplicación y sobre cómo se relacionan entre sí, consulte Objetos de aplicación y de entidad de servicio.

Diagrama que muestra el consentimiento de un usuario para una aplicación de un solo nivel.

Los permisos solicitados por la aplicación tienen un impacto en la experiencia de consentimiento. La Plataforma de identidad de Microsoft admite dos tipos de permisos;

  • Delegado: este permiso concede a una aplicación la posibilidad de actuar como un usuario que inicia sesión para un subconjunto de las cosas que el usuario puede hacer. Por ejemplo, puede conceder a una aplicación el permiso delegado para leer el calendario del usuario que ha iniciado la sesión.
  • Solo aplicación: este permiso se concede directamente a la identidad de la aplicación. Por ejemplo, puede conceder a una aplicación el permiso de solo aplicación para leer la lista de usuarios de un inquilino, con independencia de quién haya iniciado sesión en la aplicación.

Los usuarios normales pueden dar su consentimiento a algunos permisos, mientras que el resto requieren el consentimiento de un administrador de inquilinos.

Para más información sobre el consentimiento del usuario y del administrador, consulte Configuración del flujo de trabajo de consentimiento del administrador.

Los permisos de solo aplicación siempre requieren el consentimiento del administrador de inquilinos. Si la aplicación solicita un permiso de solo aplicación y un usuario intenta iniciar sesión en la aplicación, aparece un mensaje de error que indica que el usuario no puede dar su consentimiento.

Algunos permisos delegados también requieren el consentimiento del administrador de inquilinos. Por ejemplo, la posibilidad de reescribir en Microsoft Entra como el usuario que ha iniciado la sesión requiere el consentimiento del administrador de inquilinos. Al igual que los permisos de solo aplicación, si un usuario ordinario intenta iniciar sesión en una aplicación que solicita un permiso delegado que requiere el consentimiento del administrador, la aplicación recibe un error. El desarrollador que publicó el recurso determina si un permiso requiere consentimiento del administrador y puede encontrar esta información en la documentación del recurso. La documentación de permisos de Microsoft Graph API indica qué permisos requieren consentimiento del administrador.

Si la aplicación usa permisos que requieren el consentimiento del administrador, considere la posibilidad de agregar un botón o un vínculo donde el administrador pueda iniciar la acción. La solicitud que la aplicación envía para esta acción es la solicitud de autorización habitual de OAuth2 o OpenID Connect que también incluye el parámetro de cadena de consulta prompt=consent. Una vez que el administrador haya dado su consentimiento y la entidad de servicio se haya creado en el inquilino del cliente, las solicitudes de inicio de sesión posteriores no necesitan el parámetro prompt=consent. Dado que el administrador ha aprobado los permisos solicitados, no se solicitará consentimiento a ningún otro usuario en el inquilino.

Un administrador de inquilinos puede deshabilitar la posibilidad de que los usuarios normales den su consentimiento a las aplicaciones. Si esta capacidad está deshabilitada, para que la aplicación se use en el inquilino siempre se solicitará el consentimiento del administrador. Puede probar la aplicación con el consentimiento del usuario final deshabilitado, en el Centro de administración Microsoft Entra. En Aplicaciones empresariales>Consentimiento y permisos, active la opción No permitir el consentimiento del usuario.

El parámetro prompt=consent también se puede utilizar en las aplicaciones que solicitan permisos que no requieren el consentimiento del administrador. En un caso de uso de ejemplo, una aplicación que requiere una experiencia en la que el administrador del inquilino se "registra" una vez y no se solicita a otros usuarios que den su consentimiento a partir de entonces.

Si una aplicación requiere el consentimiento del administrador y un administrador inicia sesión sin enviar el parámetro prompt=consent, cuando el administrador conceda su consentimiento correctamente a la aplicación, se aplicará solo para su cuenta de usuario. Los usuarios normales seguirán sin poder iniciar sesión ni dar su consentimiento a la aplicación. Esta característica resulta útil si quiere dar al administrador de inquilinos la posibilidad de explorar la aplicación antes de permitir el acceso a otros usuarios.

La aplicación puede tener varios niveles, cada uno representado por su propio registro en Microsoft Entra ID. Por ejemplo, una aplicación nativa que llama a una API web o una aplicación web que llama a una API web. En ambos casos, el cliente (aplicación nativa o aplicación web) solicita permisos para llamar al recurso (API web). Para que la aplicación nativa o la aplicación web se acepten correctamente como inquilinos del cliente, todos los recursos a los que solicitan permisos deben ya existir en el inquilino del cliente. Si no se cumple esta condición, Microsoft Entra devuelve un error indicando que primero se debe agregar el recurso.

Múltiples niveles en un solo inquilino

Si la aplicación lógica consta de dos o más registros de aplicaciones, por ejemplo, un cliente y un recurso independientes, puede encontrar algunos problemas. Por ejemplo, ¿cómo se convierte primero el recurso en el inquilino externo? Microsoft Entra aborda este caso al habilitar el consentimiento del cliente y del recurso en un solo paso. El usuario ve la suma total de los permisos solicitados por el cliente y el recurso en la página de consentimiento. Para permitir este comportamiento, el registro de la aplicación del recurso debe incluir el identificador de la aplicación del cliente como un elemento knownClientApplications en su manifiesto de aplicación. Por ejemplo:

"knownClientApplications": ["12ab34cd-56ef-78gh-90ij11kl12mn"]

Puede consultar el ejemplo de aplicación multiinquilino para obtener una demostración. En el diagrama siguiente se ofrece información general sobre el consentimiento de una aplicación de niveles múltiples registrada en un solo inquilino.

Diagrama que muestra el consentimiento para aplicaciones cliente conocidas de varios niveles.

Múltiples niveles en varios inquilinos

Un caso parecido tiene lugar si los diferentes niveles de una aplicación se registran en distintos inquilinos. Por ejemplo, considere el caso de la creación de una aplicación cliente nativa que llama a la API de Exchange Online. Para desarrollar la aplicación nativa y, más tarde, para que se ejecute en el inquilino de un cliente, la entidad de servicio de Exchange Online debe existir. En este caso, el desarrollador y el cliente tienen que comprar Exchange Online para que la entidad de servicio se cree en sus inquilinos.

Si se trata de una API creada por una organización que no sea Microsoft, el desarrollador de la API debe proporcionar una forma de que sus clientes acepten dar su consentimiento a la aplicación en los inquilinos del cliente. El diseño recomendado tiene la finalidad de que el desarrollador de terceros cree la API de tal forma que también pueda funcionar como un cliente web para implementar el registro. Puede;

  1. Consulte las secciones anteriores para asegurarse de que la API implementa los requisitos de código y el registro de aplicaciones multiempresa.
  2. Además de exponer los roles y ámbitos de la API, asegúrese de que el registro incluye el permiso predeterminado "Iniciar sesión y leer el perfil del usuario".
  3. Implemente una página de inicio de sesión o registro en el cliente web y siga las instrucciones sobre el consentimiento de administrador.
  4. Una vez que el usuario da su consentimiento a la aplicación, se crean los vínculos a la delegación de consentimiento y a la entidad de servicio en el inquilino, y la aplicación nativa puede obtener tokens para la API.

En el diagrama siguiente se ofrece información general sobre el consentimiento de una aplicación de múltiples niveles registrada en diferentes inquilinos.

Diagrama que muestra el consentimiento para aplicaciones multiinquiilino de terceros.

Los usuarios y administradores pueden revocar el consentimiento a la aplicación en cualquier momento:

  • Los usuarios revocan el acceso a aplicaciones individuales quitándolas de su lista Aplicaciones del panel de acceso.
  • Los administradores revocan el acceso a las aplicaciones quitándolas de Azure AD mediante la sección de Aplicaciones empresariales de Centro de administración Microsoft Entra. Seleccione la aplicación y vaya a la pestaña Permisos para revocar el acceso.

Si un administrador da su consentimiento para una aplicación a todos los usuarios de un inquilino, los usuarios no pueden revocar el acceso de forma individual. Solo el administrador puede revocar el acceso y solo para la aplicación entera.

Aplicaciones multiempresa y almacenamiento en caché de los tokens de acceso

Las aplicaciones multiempresa también pueden obtener tokens de acceso para llamar a las API que están protegidas por Microsoft Entra ID. Un error común al usar la biblioteca de autenticación de Microsoft (MSAL) con una aplicación multiinquilino es solicitar inicialmente un token para un usuario con /common, recibir una respuesta y, luego, solicitar un token posterior para ese mismo usuario también mediante /common. Dado que la respuesta de Microsoft Entra proviene de un inquilino, y no de /common, MSAL almacena en caché el token como si fuera el inquilino. La llamada posterior a /common para obtener un token de acceso para el usuario carece de la entrada de caché, y se pide al usuario que inicie la sesión de nuevo. Para evitar la pérdida de la caché, asegúrese de que las posteriores llamadas para un usuario que ya ha iniciado sesión se realizan al punto de conexión del inquilino.

Consulte también