Netzwerkfluss-Matrix (SSO / Firewall)
Diese Seite listet die Netzwerkflüsse auf, die freigegeben werden müssen, damit FoxPlan und Single Sign-On (SSO) korrekt funktionieren – insbesondere hinter einem VPN, einem Unternehmens-Proxy oder einer Firewall mit SSL-Inspektion.
Sie deckt alle unterstützten SSO-Anbieter ab: Microsoft / Entra ID, Google, Atlassian (Jira), Okta und jeden benutzerdefinierten OIDC-Anbieter (einschließlich Keycloak).
So lesen Sie diese Matrix
Eine SSO-Anmeldung umfasst zwei unterschiedliche Flusskategorien:
- Browser-Flüsse — vom Gerät des Benutzers ausgehend (Anmeldeseite des Anbieters, Rückkehr zu FoxPlan). Diese laufen über das VPN / den Proxy des Benutzers und verursachen bei Blockierung Anmeldefehler oder Schleifen.
- Server-Flüsse — vom FoxPlan-Backend zum Identitätsanbieter (Token-Austausch, Signaturschlüssel, Benutzerprofil). Im SaaS-Betrieb stammen diese Aufrufe aus der FoxPlan-Infrastruktur und betreffen die Firewall des Kunden nicht. Im On-Premise-Betrieb muss der FoxPlan-Server des Kunden sie ausgehend senden.
Alle Flüsse verwenden HTTPS (TCP/443).
SSO stützt sich auf ein Status-Cookie (oauth2_auth_request, SameSite=Lax, Secure). Ein Proxy, der dieses Cookie entfernt, umschreibt oder inspiziert, verhindert, dass FoxPlan die Rückkehr validiert: die Seite läuft in einer Schleife. Die folgenden Domänen müssen ohne SSL-Inspektion und ohne Cookie-Umschreibung freigegeben werden.
Browser-Flüsse (Benutzergerät → Internet)
Diese Flüsse laufen über das VPN / den Proxy des Benutzers. Auf den Geräten freigeben. Alle über HTTPS (TCP/443). Geben Sie nur die Zeile(n) frei, die dem/den von Ihnen genutzten SSO-Anbieter(n) entsprechen.
| Anbieter | Freizugebende Domänen (Anmeldeseite + Ressourcen) |
|---|---|
| FoxPlan (immer) | app.fox-plan.com |
| Microsoft / Entra ID | login.microsoftonline.com, login.microsoft.com, login.live.com, *.msftauth.net, *.msauth.net, *.msauthimages.net |
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com | |
| Atlassian / Jira | auth.atlassian.com |
| Okta | <Ihr-Tenant>.okta.com, *.oktacdn.com |
| Benutzerdefiniertes OIDC / Keycloak | Domäne Ihres Identitätsanbieters |
Das CSS, die Bilder und die Schriftarten der Anmeldeseite werden von der Seite des Anbieters, auf dessen eigener Domäne (Microsoft, Google…) geladen und nicht von FoxPlan — das an diesem Schritt nie beteiligt ist. Sie gehören zur selben Identitäts-Endpunktgruppe des Anbieters: Wird diese Gruppe über die offizielle Liste des Anbieters (Abschnitt „Offizielle Referenzen" unten) freigegeben, sind sie abgedeckt. Keine Notwendigkeit, sie als separate Flüsse zu behandeln.
login.microsoftonline.com dient auch dem serverseitigen Token-Austausch (siehe nächster Abschnitt).
Server-Flüsse (FoxPlan-Backend → Identitätsanbieter)
Im SaaS-Betrieb stammen diese Flüsse aus der FoxPlan-Infrastruktur und müssen nicht in der Firewall des Kunden geöffnet werden. Im On-Premise-Betrieb müssen sie ausgehend vom FoxPlan-Server freigegeben werden.
| Domäne (FQDN) | Port | Rolle | Anbieter |
|---|---|---|---|
login.microsoftonline.com | 443 | Token-Austausch + Signaturschlüssel (JWKS) | Microsoft |
graph.microsoft.com | 443 | Benutzerprofil (userinfo) | Microsoft |
accounts.google.com | 443 | OIDC-Discovery / Schlüssel (JWKS) | |
oauth2.googleapis.com | 443 | Token-Austausch | |
www.googleapis.com | 443 | Signaturschlüssel (JWKS) | |
openidconnect.googleapis.com | 443 | Benutzerprofil (userinfo) | |
auth.atlassian.com | 443 | Token-Austausch | Atlassian |
api.atlassian.com | 443 | Benutzerprofil (/me) | Atlassian |
<Ihr-Tenant>.okta.com | 443 | Token, Schlüssel (JWKS), userinfo | Okta |
| Domäne Ihres IdP | 443 | Token, Schlüssel (JWKS), userinfo | Keycloak / benutzerdefiniertes OIDC |
Eingehende Flüsse (Identitätsanbieter → FoxPlan)
Es wird kein eingehender Server-Fluss vom Identitätsanbieter zu FoxPlan initiiert. Die „Rückkehr" einer Anmeldung (OIDC-Autorisierungscode) wird vom Browser des Benutzers an app.fox-plan.com übertragen (bereits durch die obigen Browser-Flüsse abgedeckt) und nicht durch eine von den Servern des Anbieters ausgehende Verbindung.
Firewall-Konsequenz: Es ist nicht erforderlich, eine eingehende Regel von den Adressbereichen des Anbieters (Microsoft, Google, Okta…) zu FoxPlan zu öffnen.
FoxPlan implementiert kein Back-Channel-Logout: Es ist kein weiterer eingehender Fluss vom IdP zu erwarten.
Anwendungsflüsse (ohne SSO)
Über SSO hinaus verwendet die FoxPlan-Anwendung die folgenden Browser-Flüsse (HTTPS/443).
Erforderlich für die ordnungsgemäße Funktion der Anwendung:
| Domäne (FQDN) | Rolle |
|---|---|
app.fox-plan.com | Anwendung und Dokumentation (/docs) |
Die FoxPlan-Oberfläche verwendet keine entfernten Schriftarten (keine Google Fonts): Sie bündelt ihre Schriftarten, sodass für die Darstellung kein zusätzlicher Fluss erforderlich ist.
Optional — die Anwendung funktioniert ohne sie; das Blockieren deaktiviert nur die zugehörige Funktion:
| Domäne (FQDN) | Rolle | Wenn blockiert |
|---|---|---|
js.hs-scripts.com, js.hs-analytics.net, js.hs-banner.com, js.hscollectedforms.net, js.hsadspixel.net, js.usemessages.com | HubSpot (Support / Messung) | Kein HubSpot-Widget |
- Reichweitenmessung: erfolgt serverseitig über Plausible; der Browser lädt kein Analyse-Skript eines Drittanbieters (Google Tag Manager / Analytics wurden entfernt).
- Fehlerübermittlung (Sentry): Das Browser-SDK sendet seine Ereignisse an unsere eigene API (
/api/commons/sentry-tunnel, ein First-Party-Tunnel), und das Backend leitet sie an den Sentry-Ingest weiter — der Browser kontaktiert also nichtingest.sentry.io.
Beide sind ausgehende serverseitige Flüsse (FoxPlan-Infrastruktur im SaaS-Betrieb, keine Auswirkung auf die Firewall des Kunden; im On-Premise-Betrieb erfolgt Plausible nur, wenn konfiguriert).
Im SaaS-Betrieb stammen die ausgehenden serverseitigen Flüsse (E-Mail-Versand, Objektspeicherung, Benachrichtigungen, serverseitige Fehlerübermittlung, Plausible-Reichweitenmessung) aus der FoxPlan-Infrastruktur und betreffen die Firewall des Kunden nicht. Im On-Premise-Betrieb geben Sie den HTTPS-Ausgang des FoxPlan-Servers zu den von Ihnen konfigurierten Diensten frei (E-Mail-Anbieter, S3-Objektspeicher, Plausible falls zutreffend usw.).
VPN- / Proxy- / Firewall-Aufmerksamkeitspunkte
- Keine SSL-Inspektion und keine Cookie-Umschreibung auf
app.fox-plan.comoder den Identitätsdomänen: Das ist die häufigste Ursache für SSO-Anmeldungen, die „in einer Schleife laufen". - Domänen freigeben über TCP/443, ohne Proxy-Authentifizierungs-Zwischenseite (Captive Portal) im Rückkehrfluss.
- Split-Tunnel: Wenn der Proxy nicht angepasst werden kann, diese Domänen vom VPN-Tunnel ausschließen.
- Antworten nicht kürzen: Identitätsantworten (Tokens) können 8 KB überschreiten; auf Proxy-Seite ausreichende Puffer vorsehen.
- Weiterleitungen zulassen zwischen
app.fox-plan.comund der Anbieterdomäne (302) ohne URL-Umschreibung.
Offizielle Referenzen
Host-Listen ändern sich mit der Zeit; beziehen Sie sich auf die offizielle Quelle jedes Anbieters:
- Microsoft / Entra ID — Endpunktsätze 56 (Identität) und 59 (Anmelderessourcen) der offiziellen Liste der Microsoft-365-URLs und IP-Adressbereiche.
- Google — Endpunkte in der OpenID-Konfiguration von Google.
- Atlassian — Atlassian-OAuth-2.0-(3LO)-Dokumentation.
- Okta — Endpunkte Ihrer Okta-Domäne (
https://<Ihr-Tenant>.okta.com/.well-known/openid-configuration).
Beim Selbst-Hosting ersetzen Sie app.fox-plan.com durch Ihre eigene Domäne. Interne Flüsse (MongoDB-Datenbank, Redis-Cache, interne Dienste) bleiben innerhalb des Clusters und sind von dieser Matrix nicht betroffen — siehe On-Premise (Kubernetes / Docker).