RHey @TOttenhus :gigipixel: Thanks for reaching out! Yes, we can handle this use case - Here are some docs that should help you along your journey - Please let me know if you have any other questions!
HHi @TOttenhus ,
We have an almost identical use case and have been mapping out a solution. We'd love to share our approach, as it seems to solve your core problem as well. We are also using Zitadel as a federation gateway, but for RENATER (the French equivalent of DFN AAI / eduGAIN). Like you, we have the hard constraint of a single SP entityID that the federation (RENATER) will register.
Our requirements are focused on the pre-login flow, as we need to manage activation on a per-client basis:
We have an almost identical use case and have been mapping out a solution. We'd love to share our approach, as it seems to solve your core problem as well. We are also using Zitadel as a federation gateway, but for RENATER (the French equivalent of DFN AAI / eduGAIN). Like you, we have the hard constraint of a single SP entityID that the federation (RENATER) will register.
Our requirements are focused on the pre-login flow, as we need to manage activation on a per-client basis:
- Single SP entityID: RENATER will only register our service once. We cannot create a new SP Application for each university.
- Per-Client Activation: We must be able to enable or disable the federation login on a per-client basis (i.e., per Zitadel Organization). This allows us to manage which of our clients (e.g., "Example University A") has this capability enabled, while others (e.g., "Example University B") do not.
- Clean UX: The "Login with RENATER" button must not appear on the default login page (which our non-university clients also see). The login flow must be driven by Zitadel's Domain Discovery based on the user's email.
HWe believe we've found a way to handle this by combining an Instance-level IdP with Organization-level IdP.
- Federation IdP & SP (Instance Level): We added the federation's metadata file as an Instance-level IdP. Make sure it is not enabled at the Instance level. This one configuration step also generates a metadata URL for Zitadel's SP endpoint. This is the single metadata URL (Constraint #1) we will give to RENATER to register our entire service. This just makes the IdP available in the instance's "palette," but doesn't activate it for anyone by default.
- Federated Client (Constraint #2): For "Example University A," we created a Zitadel Organization. We added and verified their domain (example-univ-a.fr) and enabled both Domain Discovery and External Login for this Org. In the Identity Providers for that specific Org, we enabled the "MockSAML / RENATER" IdP from the instance list.
- Local-Only Client (Constraint #2 & #3): For "Example University B," we also create an Org and add their domain (example-univ-b.fr). However, in their Identity Providers for that specific Org, we simply do not enable the "MockSAML / RENATER" IdP.
- A user from a non-university client sees the default login, and the "RENATER" button is never shown.
- A user enters user@example-univ-b.fr (local-only client). Domain Discovery finds the Org. The Org's login settings are loaded, which only shows the local password option.
- A user enters user@example-univ-a.fr (federated client). Domain Discovery finds their Org. The Org's login settings are loaded, and the user is directly redirected to the federation IdP (RENATER).
HThis setup seems to solve the single-SP, multi-tenant federation problem by leveraging Domain Discovery and the separation of Instance-level IdPs from Org-level Identity Providers. We'd appreciate any insights on whether this is the correct, idiomatic "Zitadel way" to handle this use case. It feels like the right way to build, but we want to be sure we're using the platform as intended before going live. Perhaps @Rajat or @Matías might be able to confirm if this is a recommended approach?
Thanks!
Thanks!
HUpdate
We tried to configure RENATER Test federation using the following resources :
Are we missing something ?
Thanks
We tried to configure RENATER Test federation using the following resources :
- Documentation : https://services.renater.fr/federation/en/documentation/generale/federation-de-test
- URL Metadata : tested both https://pub.federation.renater.fr/metadata/test/preview/preview-all-renater-test-metadata.xml and https://pub.federation.renater.fr/metadata/test/all.xml
Are we missing something ?
Thanks
Cliquez ici pour la version française Test federation 1. Presentation The test federation allows to test the installation, configuration and operation of your IdP and/or SP components. It is not supposed to include any production services, and there is no availability or sustainability requirements for entities registered therein.
MHi @Helixo, the set up you describe sounds good to me, should definitely work for the use case you describe 
Regarding the issue you just mentioned:
Regarding the issue you just mentioned:
Unfortunately, I am always redirected to the first IdP available (CHU Limoges) instead of being prompted to select the correct IdP from the federation.In the above screenshots you only seem to have one IdP per Organization (the instance-level RENATER SAML IdP), did you add another now? can you provide your updated set up?
HHi @Matías ,
Thanks for the follow-up. I haven't added any other conflicting IdPs. To simplify, I've just activated this one IdP at the Instance-level (I named it "RENATER Test Federation") and I have no other IdPs configured.
It seems related to how Zitadel appears to be parsing the federation metadata file. Here is what's happening:
Thanks !
Thanks for the follow-up. I haven't added any other conflicting IdPs. To simplify, I've just activated this one IdP at the Instance-level (I named it "RENATER Test Federation") and I have no other IdPs configured.
It seems related to how Zitadel appears to be parsing the federation metadata file. Here is what's happening:
- The URL I used for the Instance-level IdP is https://pub.federation.renater.fr/metadata/test/all.xml.
- This is not a metadata file for a single entity (<EntityDescriptor>). It's a federation catalogue (an <EntitiesDescriptor>) that contains hundreds of IdPs in a list.
- When Zitadel's "Import Metadata" feature parses this file, it doesn't seem to recognize it as a federation that requires a Discovery Service (WAYF).
- Instead, it just parses the XML and seams to select the very first <EntityDescriptor> it finds in that list that appears to be "CHU Limoges".
Thanks !
HIn the meantime, I came across this issue you created that seams related to our use case. Am I wrong ?
GitHub
Preflight Checklist I could not find a solution in the existing issues, docs, nor discussions I have joined the ZITADEL chat Describe your problem Today, when ZITADEL acts as a SAML Identity Provid...
HHi !
Do you have any insight to share regarding this use case ?
Thanks
Do you have any insight to share regarding this use case ?
Thanks
HHello @Matías ,
Do you need more information ?
Thank you
Do you need more information ?
Thank you
MHi @Helixo, thanks for the ping, I had lost track of the thread. Please find my answers below:
You have a couple practical paths:
- Your multi-tenant design is sound: one SAML IdP at the instance level (disabled globally) + enable it per-Org via Domain Discovery so only selected Orgs get “Login with RENATER.”
- The problem isn’t the toggle/UX—it’s the RENATER metadata you imported. You fed Zitadel a federation catalog (
<EntitiesDescriptor>, hundreds of IdPs). Zitadel’s import doesn’t treat it as a federation with its own Discovery Service (WAYF); it effectively locks onto the first IdP entry it finds (CHU Limoges), so users get auto-redirected there instead of being prompted to choose their university.
- Zitadel’s SAML IdP config expects a single IdP metadata (
<EntityDescriptor>). - A federation catalog requires IdP discovery/selection logic (WAYF/DS). Zitadel doesn’t act as a federation discovery service during import, this is not supported, so it picks the first entity and redirects to it.
You have a couple practical paths:
- **Per-IdP metadata (simple, but manual):**For each university Org, import **that university’s single-entity metadata** (or a **filtered** 1-entity XML you host) and enable it only for that Org. This preserves your Domain Discovery flow and keeps the “RENATER” button hidden elsewhere.
- **Put a SAML proxy/DS in front (cleanest UX at scale):**Use a broker/proxy (e.g., **SATOSA**, **Keycloak broker**, **SimpleSAMLphp** with a discovery module) against RENATER’s federation feed. Configure **Zitadel to trust the proxy as a single IdP**. The proxy handles IdP selection and keeps your **single SP entityID** with RENATER. This is a more involved solution.
HOk thank you !
G