Planifique la integración del SSO con Microsoft Entra ID (ISV)

El inicio de sesión único (SSO) con Microsoft Entra ID realiza el planeamiento. Las decisiones tempranas afectan a la arquitectura de la aplicación, la incorporación de clientes y el mantenimiento a largo plazo. Esta guía ayuda a los proveedores independientes de software (ISV) a tomar esas decisiones antes de desarrollar.

El planeamiento del inicio de sesión único para proveedores de software independientes (ISV) difiere del inicio de sesión único de la organización. Como ISV, diseñas tu aplicación una vez y luego la implementas en muchos entornos de cliente. Cada inquilino puede tener requisitos, protocolos y configuración diferentes.

Este enfoque de implementación es el modelo "diseñar una vez, configurar por inquilino". Las decisiones que tome al principio determinan lo bien que podrá atender a clientes diversos. La planificación débil conduce a la fricción de incorporación, más trabajo de soporte técnico y pérdida de ventas empresariales.

Para planear bien, en primer lugar comprenda los conceptos básicos. Para más información, consulte ¿Qué es el inicio de sesión único (SSO) y Descripción del modelo de SSO de Microsoft?

Para la mayoría de los ISV de SaaS modernos, use estos valores predeterminados:

  • Arquitectura multiinquilino: valor predeterminado para la distribución escalable de SaaS.
  • OpenID Connect (OIDC): el protocolo recomendado para el desarrollo nuevo.
  • Aplicaciones de página única (SPA) y aplicaciones móviles: debe usar OIDC.
  • SAML: elíjalo solo para requisitos específicos heredados de clientes empresariales.
  • Aplicaciones para un solo inquilino: no superan la validación de la galería de aplicaciones de Microsoft Entra.

Estos valores predeterminados recomendados coinciden con los procedimientos de desarrollo modernos y los requisitos de validación de Microsoft Entra. Si te desvías de ellos, a menudo tienes que rehacer trabajo durante la validación.

Importante

Las decisiones de diseño afectan directamente si la aplicación pasa Microsoft Entra validación y recibe un identificador de prueba. El modelo de arrendamiento o protocolo incorrecto suele provocar retrabajo.

Comprender el contexto de SSO de los ISV en Microsoft Entra ID

Microsoft Entra ID usa un modelo estructurado. La aplicación tiene una definición global denominada objeto de aplicación, que representa el registro de la aplicación compartido en todos los inquilinos. En cada inquilino, la aplicación también tiene una instancia específica del inquilino denominada entidad de servicio. Cuando un cliente agrega la aplicación a su inquilino, crea su entidad de servicio. La entidad de servicio contiene la configuración del inicio de sesión único del inquilino, las asignaciones de usuario y la configuración del protocolo.

La separación entre el objeto de aplicación y las entidades de servicio permite que la aplicación admita diferentes protocolos y configuraciones de SSO entre inquilinos, mientras que el diseño principal sigue siendo el mismo. Cada instancia configura su propia configuración de SSO de forma independiente, sin afectar a otras implementaciones.

Implicación crítica para ISV: La configuración del protocolo reside en la entidad de servicio. Así que tu aplicación debe admitir distintos protocolos de SSO y mapeos de claims en distintos tenants. Un cliente podría usar SAML con asignaciones de atributos específicas. Otro podría usar OIDC con declaraciones diferentes. La arquitectura de la aplicación debe controlar esta variación correctamente.

Para obtener una explicación detallada de este modelo, consulte Objetos de aplicación y entidades de servicio yAplicaciones de inquilino único frente a aplicaciones multiinquilino.

Decidir el modelo de arrendamiento

Para la mayoría de los ISV de SaaS, la arquitectura multiinquilino es el valor predeterminado recomendado. Puede diseñar la aplicación como inquilino único (una organización) o multiinquilino (muchas organizaciones). Esta elección afecta en gran medida al diseño de su SSO, a la complejidad del proceso de incorporación y a la capacidad de escalado de su modelo de negocio.

Las aplicaciones multiempresa (recomendadas) dan servicio a muchas organizaciones de clientes desde un único registro de aplicación. Un único registro simplifica la implementación y escala bien. Las aplicaciones multiinquilino requieren un diseño cuidadoso para el aislamiento entre inquilinos y la configuración específica para cada cliente.

Las aplicaciones de un solo inquilino necesitan una implementación independiente por cliente. Proporcionan un aislamiento más fuerte, pero agregan trabajo operativo. Elija este enfoque solo para necesidades empresariales especializadas o de cumplimiento.

Impacto en la validación y publicación:

  • Las aplicaciones de inquilino único no superan la validación para su publicación en la galería de aplicaciones de Microsoft Entra.
  • La multitenencia es necesaria para la distribución empresarial escalable y la inclusión en la galería.
  • La publicación de galerías requiere una arquitectura multicliente para dar servicio a distintos clientes.

La elección entre la arquitectura de inquilino único y multiinquilino es difícil de cambiar después de que los clientes empiecen a usar la aplicación. Para obtener información completa, consulte Aplicaciones de un solo inquilino frente a aplicaciones multiinquilino.

Definir la arquitectura de la aplicación y los patrones de inicio de sesión

La arquitectura de la aplicación determina qué flujos de autenticación y patrones de SSO puede admitir. Elija la arquitectura y el protocolo juntos y elija cuidadosamente. Una coincidencia deficiente hace que se vuelva a trabajar durante la validación.

Alineación recomendada del protocolo de arquitectura:

  • Aplicaciones de página única (SPAs) → se requiere OIDC (gestión de tokens en el cliente)
  • Se requieren aplicaciones móviles → OIDC (flujos de autenticación nativos)
  • Aplicaciones web modernas → valor predeterminado de OIDC (control de tokens del lado servidor)
  • Aplicaciones empresariales heredadas → SAML aceptable (federación basada en XML)

Las aplicaciones web pueden usar SAML o OpenID Connect, pero OIDC es el valor predeterminado recomendado para el nuevo desarrollo. Las aplicaciones de página única y las aplicaciones móviles funcionan mejor con OIDC porque se ejecutan en el cliente y usan patrones de autenticación modernos.

Note

Si elige incorrectamente: las opciones de arquitectura y protocolo mal alineadas suelen requerir un trabajo importante durante la validación y pueden retrasar la publicación de la galería.

Para obtener instrucciones detalladas sobre los tipos de aplicación y los patrones de autenticación, consulte Tipos de aplicación de la plataforma de identidad de Microsoft y flujo de concesión de código de autorización de OAuth 2.0.

Revisión de consideraciones de planeación específicas del protocolo

Los ISV deben elegir entre SAML 2.0 y OpenID Connect (OIDC) para el inicio de sesión único. Para la mayoría de los ISV de SaaS modernos, OIDC es el valor predeterminado recomendado. Coincide con los procedimientos de desarrollo modernos, admite arquitecturas de aplicaciones modernas e integra más sencillamente.

Elija SAML solo para requisitos de cliente empresariales específicos o necesidades de integración heredadas. SAML sigue siendo ampliamente compatible y se ajusta a algunos escenarios, pero normalmente se tarda más en implementar y configurar.

La elección del protocolo afecta directamente a la validación correcta y a la generación del identificador de prueba. Las aplicaciones que usan patrones y protocolos recomendados suelen pasar Microsoft Entra validación más rápida. Las opciones no estándar pueden necesitar ciclos de validación adicionales.

Para obtener una comparación detallada y un marco de decisión, consulte SAML frente a OpenID Connect: Elija el protocolo SSO adecuado.

Planear la configuración del cliente y la experiencia de incorporación

Mantenga la configuración sencilla, pero permita la personalización que los clientes necesitan. Algunos valores son los mismos para cada cliente, como los URI de redirección y los identificadores de aplicación. Otros aspectos varían según el cliente, como el mapeo de declaraciones y los atributos de usuario.

Diseño primero para la automatización:

  • Automatizar las configuraciones estándar siempre que sea posible
  • Proporcionar instrucciones claras para la configuración específica del cliente
  • Planear cómo los clientes obtendrán y validarán los valores de configuración
  • Prueba del proceso de incorporación con varios escenarios de cliente

El diseño de incorporación deficiente afecta directamente a la adopción del cliente y a la sobrecarga de soporte técnico. Para conocer los conceptos de configuración, consulte Conceptos de registro de aplicaciones, documentación de metadatos de SAML y Guía de URI de redirección.

Declaraciones del plan, datos de identidad y mapeo de autorizaciones

Defina las reclamaciones obligatorias y opcionales desde el principio. Algunas declaraciones, como el identificador de usuario, suelen ser obligatorias. Otros, como pertenencias a grupos y atributos personalizados, pueden ser opcionales o específicos del cliente.

Planear la variabilidad del cliente:

  • Los distintos clientes tienen diferentes datos de identidad disponibles
  • Las preferencias de formato y entrega de las reclamaciones varían entre los distintos inquilinos
  • Prueba de la aplicación con escenarios de notificación mínimos y enriquecidos
  • Documente el comportamiento de respaldo cuando faltan reclamaciones opcionales

Para conocer los conceptos de notificaciones y tokens, consulte Información general sobre tokens y notificaciones, tokens de identificador y tokens de seguridad.

Planear el cierre de sesión, el ciclo de vida y las operaciones a largo plazo

SSO va más allá del primer inicio de sesión. Planifique con antelación el cierre de sesión, la gestión de sesiones y el ciclo de vida de la cuenta. Estas necesidades suelen surgir como requisitos de cliente durante las ventas empresariales.

Escenarios clave para abordar:

  • Cierre de sesión único entre aplicaciones
  • Alineación del tiempo de espera de sesión con directivas organizativas
  • Desactivación y limpieza de cuentas
  • Control de actualización y expiración de tokens

Para obtener instrucciones de implementación, consulte la documentación de cierre de sesión de OpenID Connect y las referencias de cierre de sesión de SAML en la documentación del protocolo SAML.

Planee los requisitos de la galería desde el principio. Para publicar en la galería de aplicaciones de Microsoft Entra, debe cumplir estándares de integración específicos y pasar pruebas de validación para obtener un identificador de prueba.

Factores de éxito de validación:

  • Arquitectura multiinquilino (obligatorio)
  • Cumplimiento del protocolo (OIDC recomendado para una validación más rápida)
  • Flujos de autenticación estándar y control de errores
  • Gestión correcta de declaraciones y tokens

Las aplicaciones que siguen patrones establecidos suelen pasar la validación más rápido. Las decisiones de planificación deficientes a menudo se manifiestan en forma de fallos de validación que requieren una reelaboración considerable.

Para obtener instrucciones de publicación y requisitos de validación, consulte la documentación de la galería de aplicaciones de Microsoft Entra.

Lista de comprobación de preparación para la planificación del inicio de sesión único

Use las tablas siguientes para confirmar que está listo para la validación y la publicación en la galería. Cada elemento se asigna a una decisión de planeación de SSO clave: modelo de inquilino, arquitectura de aplicaciones, opción de protocolo, configuración del cliente, notificaciones y cierre de sesión.

Lista de comprobación de diseño de aplicaciones

Confirme estas opciones de diseño de aplicaciones antes de la validación.

Elemento de preparación ¿Por qué es importante?
Modelo multiinquilino confirmado La galería de aplicaciones Microsoft Entra solo acepta aplicaciones multiinquilino.
Arquitectura de aplicación definida (web, SPA, móvil o API) La arquitectura determina qué flujos de autenticación se aplican.
Flujos de autenticación identificados y alineados con la arquitectura Los flujos desalineados provocan errores de validación.

Lista de comprobación de selección de protocolo

Confirme la elección del protocolo y sus implicaciones.

Elemento de preparación ¿Por qué es importante?
OIDC por defecto confirmado o justificación comercial documentada para SAML OIDC es el valor predeterminado recomendado; las desviaciones necesitan justificación.
La elección del protocolo se alinea con la arquitectura de la aplicación Las SPA y las aplicaciones móviles requieren OIDC.
Implicaciones específicas del protocolo que se entienden para el tipo de aplicación Evita el rediseño en fase tardía durante la validación.

Lista de comprobación de la experiencia del cliente

Revise la experiencia de incorporación y configuración de los clientes.

Elemento de preparación ¿Por qué es importante?
Valores de configuración clasificados como fijos o específicos del cliente Controla las instrucciones de incorporación y el modelo de inquilino.
Proceso de incorporación diseñado para minimizar la complejidad del cliente Reducir la fricción mejora la adopción por parte de los administradores del inquilino.
Requisitos de declaraciones y datos de identidad definidos y probados Impide que las autorizaciones no coincidan en tiempo de ejecución.

Lista de comprobación de validación y publicación

Confirme la validación y la preparación de la publicación.

Elemento de preparación ¿Por qué es importante?
Requisitos de publicación de la galería revisados al principio del desarrollo Evita volver a trabajar antes del envío.
Impacto de la validación de las decisiones de diseño consideradas Algunas decisiones bloquean completamente la validación.
Enfoque previsto para el cierre de sesión y la gestión de sesiones Necesario para el cumplimiento y una experiencia de usuario limpia.
Escenarios de ciclo de vida de la cuenta probados Detecta casos límite de desaprovisionamiento.

Lista de comprobación previa a la validación

Complete esta comprobación final antes de iniciar la validación.

Elemento de preparación ¿Por qué es importante?
Todas las decisiones críticas documentadas y justificadas Agiliza las transferencias y reduce la repetición del trabajo.
Ruta de validación del identificador de prueba confirmada Obligatorio antes de entrar en el flujo de publicación.
Riesgo de retrabajo evaluado y minimizado Último punto de control de aprobación o rechazo antes de la validación.

Contenido relacionado

Use estos recursos para registrar, validar y publicar la aplicación.

Para desarrolladores de aplicaciones de ISV:

Para administradores de TI:

  • Last updated on