I'm setting up multiple SAML clients within a single Keycloak realm (Keycloak is the IdP). The idea is to have multiple SAML clients for the same SP within the same realm. SAML client 1 will be used by Entity A and SAML client 2 will be used by Entity B.
The Service Provider is an external application for which the Issuer in the SAMLRequest is the same for all customers (let's call it https://test.net/).
Creating the 1st SAML client in Keycloak is no problem, all works fine. When creating the second SAML client in the same Keycloak realm, I get an error when setting the Client ID because the Client ID usually needs to match the SP Issuer but since https://test.net/ is already taken by the Client ID of the 1st SAML client in Keycloak, I cannot add a second SAML client with the same Client ID.
If I change the Client ID of the second SAML client to something else other than https://test.net/, then the SAML flow breaks because the Issuer passed in the SAMLRequest by the SP does not match the Client ID of the 2nd SAML client in Keycloak.
Other IdPs such as Azure AD and Okta provide a unique Login SAML endpoint per SAML Client so that by the time the SP calls the IdP SAML endpoint the IdP already know which SAML client the user should be authenticated against, and does not rely on the SP Issuer.
How can I have a unique SAML endpoint per SAML client in the same Realm so that Keycloak does not solely rely on the SP Issuer?
I have found a solution for this problem. Keycloak won't allow to have a unique SAML endpoint per SAML client within the same Realm (for the "SP-initiated login") but it does provide a unique URL per SAML client within the same Realm for the "IdP-initiated login".
So the solution was to enter the unique IdP-initiated login URL per SAML client as the SAML endpoint in the external application (on the Service Provider SSO settings). This forwards the user to the IdP-initiated login flow (even if the user initiates the SSO login on the SP side) and since the URL is unique to a respective SAML client, Keycloak already knows which SAML client the user is to be authenticated against making the flow fully independent from the SP Issuer/Client ID