As far as I know, SAML doesn't offer any mechanism for what you want. SAML discovery is used to find out which IdP exist for your application.

Your problem is that you don't know who the user is before it tries to log in and when he does, it means that he already know which IdP he wants to use.

So you have these options:

1. Most common. Use a landing page that lets the user select which IdP to use. For example, Epic games lets you select the IdP from a list of 8. Once the user selects it, then you are good to go, by directing his request to the correct IdP.
2. If you know in advance which user belongs to which IdP then you can have a page that lets the user enter his username only. Once he does this, you can check in your DB to which IdP this user belongs to and send a redirect message back to the browser. While this works, it will not allow the user to select which IdP it wants to use, putting this job on the shoulders of the backend.
3. Do step 2 once and save a cookie in the user's browser. Then, when the user tries to log again in another session from the same machine, you can automatically redirect him to the right IdP. Using this option, everything is done automatically and except for the first time.

One thing to consider. From a security standpoint giving a hacker any info is a bad practice and so option 2,3 do reveal to a hacker which IdP belongs to which user. IMO this is not such a big breach and can be implemented.

This is not really a SAML question, since any solution would happen outside of standards and involve identifying the user before asking them to authenticate.

GENERAL PATTERN

• App redirects to Service Provider using Technology A, eg SAML, OpenID Connect
• For this app, the Service Provider is configured to run an action, eg present a screen, to identify the user - you may have seen this in systems such as Office365
• Service Provider then uses some kind of data lookup to identify the IDPs for the next step
• If there is more than one then the user is prompted to select one, otherwise the default option is invoked automatically
• The Service Provider then redirects to the IDP using Technology B - could be SAML / OIDC / Other

EXTENSIBILITY

Hopefully my comments above show that an IAM system is a toolbox and should be extensible. I work at Curity where we use a concept of authenticators and actions which can be combined - eg for MFA, but a common option is as follows:

• Capture the user name
• Run some custom logic - eg JavaScript that invokes a data lookup to set the next authenticator

Here is a recent article to show how this works - the Username Authenticator is the interesting part.

PROVIDERS

Unfortunately Spring may not provide the options you would like. This should clarify your requirements a little though.