Hasta donde yo sé, SAML no ofrece ningún mecanismo para lo que desea. El descubrimiento de SAML se utiliza para averiguar qué IdP existen para su aplicación.

Su problema es que no sabe quién es el usuario antes de que intente iniciar sesión y cuando lo hace, significa que ya sabe qué IdP quiere usar.

Así que tienes estas opciones:

1. Más común. Use una página de destino que le permita al usuario seleccionar qué IdP usar. Por ejemplo, los juegos de Epic le permiten seleccionar el IdP de una lista de 8. Una vez que el usuario lo selecciona, puede continuar dirigiendo su solicitud al IdP correcto.
2. Si sabe de antemano qué usuario pertenece a qué IdP, puede tener una página que le permita al usuario ingresar solo su nombre de usuario. Una vez que haga esto, puede verificar en su base de datos a qué IdP pertenece este usuario y enviar un mensaje de redireccionamiento al navegador. Si bien esto funciona, no permitirá que el usuario seleccione qué IdP quiere usar, poniendo este trabajo sobre los hombros del backend.
3. Realice el paso 2 una vez y guarde una cookie en el navegador del usuario. Luego, cuando el usuario intente iniciar sesión nuevamente en otra sesión desde la misma máquina, puede redirigirlo automáticamente al IdP correcto. Usando esta opción, todo se hace automáticamente y excepto la primera vez.

Una cosa a considerar. Desde el punto de vista de la seguridad, dar información a un pirata informático es una mala práctica, por lo que las opciones 2 y 3 le revelan a un pirata informático qué IdP pertenece a qué usuario. En mi opinión, esta no es una brecha tan grande y puede implementarse.

Esta no es realmente una pregunta de SAML, ya que cualquier solución ocurriría fuera de los estándares e implicaría identificar al usuario antes de pedirle que se autentique.

PATRÓN GENERAL

• La aplicación redirige al proveedor de servicios utilizando la tecnología A, por ejemplo, SAML, OpenID Connect
• Para esta aplicación, el proveedor de servicios está configurado para ejecutar una acción, por ejemplo, presentar una pantalla, para identificar al usuario; es posible que haya visto esto en sistemas como Office365
• Luego, el proveedor de servicios utiliza algún tipo de búsqueda de datos para identificar a los desplazados internos para el siguiente paso.
• Si hay más de uno, se le solicita al usuario que seleccione uno; de lo contrario, la opción predeterminada se invoca automáticamente
• Luego, el proveedor de servicios redirige al IDP utilizando la tecnología B; podría ser SAML/OIDC/Otro

EXTENSIBILIDAD

Espero que mis comentarios anteriores muestren que un sistema IAM es una caja de herramientas y debe ser extensible. Trabajo en Curity, donde usamos un concepto de autenticadores y acciones que se pueden combinar, por ejemplo, para MFA, pero una opción común es la siguiente:

• Capturar el nombre de usuario
• Ejecute alguna lógica personalizada, por ejemplo, JavaScript que invoque una búsqueda de datos para configurar el próximo autenticador

Aquí hay un artículo reciente para mostrar cómo funciona esto: el Autenticador de nombre de usuario es la parte interesante.

PROVEEDORES

Lamentablemente, es posible que Spring no proporcione las opciones que le gustaría. Sin embargo, esto debería aclarar un poco sus requisitos.