Matrice des flux réseau (SSO / pare-feu)
Cette page liste les flux réseau à autoriser pour que FoxPlan et l'authentification unique (SSO) fonctionnent correctement, en particulier derrière un VPN, un proxy d'entreprise ou un pare-feu avec inspection SSL.
Elle couvre les différents fournisseurs SSO pris en charge : Microsoft / Entra ID, Google, Atlassian (Jira), Okta et tout fournisseur OIDC personnalisé (dont Keycloak).
Comment lire cette matrice
Une connexion SSO met en jeu deux catégories de flux distinctes :
- Flux navigateur — émis depuis le poste de l'utilisateur (page de connexion du fournisseur, retour vers FoxPlan). Ce sont ceux qui passent par le VPN / proxy de l'utilisateur et qui, en cas de blocage, provoquent des échecs ou des boucles de connexion.
- Flux serveur — émis par le backend FoxPlan vers le fournisseur d'identité (échange du jeton, clés de signature, profil utilisateur). En SaaS, ces appels partent de l'infrastructure FoxPlan et ne concernent pas le pare-feu du client. En on-premise, c'est le serveur FoxPlan du client qui doit les émettre en sortie.
Tous les flux sont en HTTPS (TCP/443).
Le SSO s'appuie sur un cookie d'état (oauth2_auth_request, SameSite=Lax, Secure). Un proxy qui supprime, réécrit ou inspecte ce cookie empêche FoxPlan de valider le retour : la page tourne en boucle. Les domaines ci-dessous doivent être autorisés sans inspection SSL ni réécriture de cookies.
Flux navigateur (poste utilisateur → Internet)
Ces flux transitent par le VPN / proxy de l'utilisateur. À autoriser sur les postes. Tous sont en HTTPS (TCP/443). N'autorisez que la ou les lignes correspondant au(x) fournisseur(s) SSO que vous utilisez.
| Fournisseur | Domaines à autoriser (page de connexion + ressources) |
|---|---|
| FoxPlan (toujours) | 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 | <votre-tenant>.okta.com, *.oktacdn.com |
| OIDC personnalisé / Keycloak | domaine de votre fournisseur d'identité |
Le CSS, les images et les polices de la page de connexion sont chargés par la page du fournisseur, sur son propre domaine (Microsoft, Google…), et non par FoxPlan — qui n'intervient jamais dans cette étape. Ils appartiennent au même groupe d'endpoints d'identité du fournisseur : autoriser ce groupe via la liste officielle du fournisseur (section « Références officielles » ci-dessous) les couvre. Inutile de les gérer comme des flux séparés.
login.microsoftonline.com sert aussi à l'échange de jeton côté serveur (voir la section suivante).
Flux serveur (backend FoxPlan → fournisseur d'identité)
En SaaS, ces flux partent de l'infrastructure FoxPlan et n'ont pas à être ouverts sur le pare-feu du client. En on-premise, ils doivent être autorisés en sortie depuis le serveur FoxPlan.
| Domaine (FQDN) | Port | Rôle | Fournisseur |
|---|---|---|---|
login.microsoftonline.com | 443 | Échange du jeton + clés de signature (JWKS) | Microsoft |
graph.microsoft.com | 443 | Profil utilisateur (userinfo) | Microsoft |
accounts.google.com | 443 | Découverte OIDC / clés (JWKS) | |
oauth2.googleapis.com | 443 | Échange du jeton | |
www.googleapis.com | 443 | Clés de signature (JWKS) | |
openidconnect.googleapis.com | 443 | Profil utilisateur (userinfo) | |
auth.atlassian.com | 443 | Échange du jeton | Atlassian |
api.atlassian.com | 443 | Profil utilisateur (/me) | Atlassian |
<votre-tenant>.okta.com | 443 | Jeton, clés (JWKS), userinfo | Okta |
| Domaine de votre IdP | 443 | Jeton, clés (JWKS), userinfo | Keycloak / OIDC personnalisé |
Flux entrants (fournisseur d'identité → FoxPlan)
Aucun flux serveur entrant n'est initié par le fournisseur d'identité vers FoxPlan. Le « retour » d'une connexion (code d'autorisation OIDC) est transporté par le navigateur de l'utilisateur vers app.fox-plan.com (déjà couvert par les flux navigateur ci-dessus), et non par une connexion émise depuis les serveurs du fournisseur.
Conséquence pare-feu : il est inutile d'ouvrir une règle entrante depuis les plages d'adresses du fournisseur (Microsoft, Google, Okta…) vers FoxPlan.
FoxPlan n'implémente pas de déconnexion par canal arrière (back-channel logout) : aucun autre flux entrant depuis l'IdP n'est à prévoir.
Flux applicatifs (hors SSO)
Au-delà du SSO, l'application FoxPlan utilise les flux navigateur suivants (HTTPS/443).
Requis pour le bon fonctionnement de l'application :
| Domaine (FQDN) | Rôle |
|---|---|
app.fox-plan.com | Application et documentation (/docs) |
L'interface FoxPlan n'utilise aucune police distante (pas de Google Fonts) : elle embarque ses polices, aucun flux supplémentaire n'est requis pour l'affichage.
Optionnels — l'application fonctionne sans ; les bloquer ne désactive que la fonctionnalité associée :
| Domaine (FQDN) | Rôle | Si bloqué |
|---|---|---|
js.hs-scripts.com, js.hs-analytics.net, js.hs-banner.com, js.hscollectedforms.net, js.hsadspixel.net, js.usemessages.com | HubSpot (support / mesure) | Pas de widget HubSpot |
- Mesure d'audience : réalisée côté serveur via Plausible ; le navigateur ne charge aucun script d'analytics tiers (Google Tag Manager / Analytics ont été retirés).
- Remontée d'erreurs (Sentry) : le SDK du navigateur envoie ses événements à notre propre API (
/api/commons/sentry-tunnel, tunnel first-party) et c'est le back qui les relaie à l'ingest Sentry — le navigateur ne contacte donc pasingest.sentry.io.
Dans les deux cas, ce sont des flux sortants serveur (infra FoxPlan en SaaS, sans effet pour le pare-feu du client ; en on-premise, Plausible n'a lieu que s'il est configuré).
En SaaS, les flux sortants côté serveur (envoi d'e-mails, stockage de fichiers objet, notifications, remontée d'erreurs serveur, mesure d'audience Plausible) partent de l'infrastructure FoxPlan et ne concernent pas le pare-feu du client. En on-premise, prévoyez la sortie HTTPS du serveur FoxPlan vers les services que vous configurez (fournisseur d'e-mail, stockage objet S3, Plausible le cas échéant, etc.).
Points de vigilance VPN / proxy / pare-feu
- Ne pas inspecter (SSL) ni réécrire les cookies sur
app.fox-plan.comni sur les domaines d'identité : c'est la cause n°1 des connexions SSO qui « tournent en boucle ». - Autoriser les domaines ci-dessus en TCP/443, sans page intermédiaire d'authentification du proxy (captive portal) sur le flux de retour.
- Split-tunnel : si le proxy ne peut pas être ajusté, exclure ces domaines du tunnel VPN.
- Ne pas tronquer les réponses : les réponses d'identité (jetons) peuvent dépasser 8 Ko ; prévoir des tampons suffisants côté proxy.
- Autoriser les redirections entre
app.fox-plan.comet le domaine du fournisseur (302) sans réécriture d'URL.
Références officielles
Les listes d'hôtes évoluent ; se référer aux sources officielles des fournisseurs :
- Microsoft / Entra ID — jeux d'endpoints 56 (identité) et 59 (ressources de connexion) de la liste officielle des URLs et plages d'adresses Microsoft 365.
- Google — endpoints publiés dans la configuration OpenID de Google.
- Atlassian — documentation OAuth 2.0 (3LO) d'Atlassian.
- Okta — endpoints de votre domaine Okta (
https://<votre-tenant>.okta.com/.well-known/openid-configuration).
En auto-hébergement, remplacez app.fox-plan.com par votre propre domaine. Les flux internes (base MongoDB, cache Redis, services internes) restent internes au cluster et ne sont pas concernés par cette matrice — voir On-premise (Kubernetes / Docker).