Estoy trabajando en la redirección de inicio de sesión de Azure AD y buscando una solución (si es posible) que me permita "inyectar" una identificación en el uri de redirección.
Para obtener más detalles, tenemos un Vue SPA y nuestra estrategia CICD es implementar el código base de la rama de características en el entorno de prueba para fines de prueba. La implementación se activa mediante la solicitud de extracción de Git (desde la característica hasta la principal), por lo que cada solicitud de extracción tendrá una implementación única (como una aplicación de revisión para este cambio de relaciones públicas).
Por ejemplo, cada implementación se expone mediante la ruta https://xxxxx.{prId}.yyyy.io. Mediante esta estrategia, podríamos aislar las pruebas para cada ticket de Jira.
Sin embargo, esto causa el problema de configuración de uri de redireccionamiento, ya que solicita configurar uri fijos en la captura de pantalla anterior. Definitivamente no quiero ingresar todas las rutas identificadas con orgullo en AD manualmente.
La pregunta es:
(1) Supongamos que tengo una nueva implementación con la ruta https://xxxxx.pr10.yyyy.io , ¿hay alguna forma de no ingresarla en AD y AD simplemente me redirige a la ruta actual después de iniciar sesión?
(2) Sé que podría haber una solución comodín (tal vez ya no se admita), pero si tengo dos o más PR, https://xxxxx.pr10.yyyy.io , https://xxxxx.pr11.yyyy. io y tengo uri comodín en AD como https://xxxxx.pr*.yyyy.io, ¿cómo podría AD saber a qué ruta redirigirme?
(3) La última solución podría ser cambiar esta estrategia de cicd al flujo de git tradicional, que es enviar todos los cambios de código a una rama de prueba e implementar esta rama de prueba para enrutar https://xxxxx.test.yyyy.io , esto podría dar us un uri fijo, pero esto causa la dificultad de probar el aislamiento y el costo de migración de cicd. Entonces, la pregunta general es ¿hay alguna manera de que podamos apegarnos a nuestro CICD actual pero usando AD? Gracias.
Después de la lectura profunda del documento del artículo oficial Restricciones y limitaciones del URI de redirección (URL de respuesta)
El uri comodín aún se admite, pero con un alcance limitado:
Actualmente, los URI comodín no son compatibles con los registros de aplicaciones configurados para iniciar sesión en cuentas personales de Microsoft y cuentas profesionales o educativas. Sin embargo, se permiten URI comodín para aplicaciones que están configuradas para iniciar sesión solo en cuentas profesionales o educativas en el arrendatario de Azure AD de una organización.
El punto clave es que no puede agregar un uri comodín, por ejemplo, https://*.domain.com en la página web directamente, sino que puede ir al editor de manifiesto e ingresarlo.
Para agregar URI de redirección con comodines a los registros de aplicaciones que inician sesión en cuentas profesionales o educativas, use el editor de manifiestos de aplicaciones en Registros de aplicaciones en Azure Portal.
Como dijo MS:
le recomendamos encarecidamente que se adhiera a la sección 3.1.2 de RFC 6749 y que utilice únicamente URI absolutos.
Pero dado que mi caso es más un propósito de prueba, entonces es aceptable. Para la producción, mejor no.