Le SSO VPN connecte-t-il automatiquement les utilisateurs aux applications internes ?

Une passerelle VPN qui s'authentifie via un fournisseur d'identité prouve une chose : le fournisseur s'est porté garant d'un utilisateur auprès de la passerelle. Elle ne remet pas à cet utilisateur un justificatif pour le wiki de l'intranet, le tableau de bord de supervision ou le serveur de compilation. Ces services connectent les personnes via leur propre fédération et appliquent leur propre autorisation, et le tunnel décide seulement quels paquets peuvent les atteindre.

Trois sessions, trois décisions distinctes

Gardez les états séparés, car chacun expire selon son propre calendrier. La session VPN est l'acceptation d'une identité par la passerelle plus l'accès réseau qu'elle a accordé. La session de navigateur chez le fournisseur d'identité est ce que le navigateur conserve encore pour ce fournisseur et peut réutiliser selon sa politique. La session applicative appartient à un service qui a validé une réponse qui lui était adressée.

Confondre ces états produit la mauvaise question, souvent formulée comme pourquoi le tunnel ne connecte pas l'utilisateur partout. Reformulez-la : quelle application n'a pas d'entrée de fédération, laquelle refuse l'utilisateur et à laquelle il manque une route. Une seule invite de connexion qui ouvre l'application intranet peut encore renvoyer vers le fournisseur, car la seconde redirection est une nouvelle demande d'autorisation pour une autre audience.

Câblez la passerelle comme sa propre application

Enregistrez le VPN comme application approuvée chez le fournisseur, avec son propre identifiant, son URI de redirection et son affectation d'utilisateurs. Décidez ensuite quelles autorisations réseau cette connexion accorde, car il s'agit d'une politique VPN et non d'une fonction du fournisseur. Les utilisateurs qui ne doivent atteindre que le sous-réseau de supervision reçoivent une autre politique de passerelle, pas un autre mot de passe.

La réponse d'authentification du tunnel n'est pas un justificatif réutilisable. Les jetons d'ID OIDC portent une revendication d'audience nommant le client pour lequel ils ont été émis, et les assertions porteuses SAML limitent l'audience au fournisseur de service destinataire. Un second service qui accepte la réponse du premier est mal configuré, et copier un jeton dans une autre application n'est pas une intégration.

Enregistrez chaque application interne, puis réglez le contexte du navigateur

Chaque service a besoin des valeurs SAML ou OIDC prises en charge : émetteur, identifiant de client, URL de rappel ou de consommateur d'assertion, revendications requises et affectation. L'accessibilité s'y ajoute, car les contrôles d'identité ne fournissent jamais de route ni de réponse DNS.

1. Créez l'entrée d'application et confirmez que l'ID d'entité ou de client correspond à ce que l'application envoie.
2. Enregistrez l'URL de rappel exacte, schéma et port compris ; un écart minime échoue après l'authentification de l'utilisateur.
3. Affectez les utilisateurs ou les groupes, puis confirmez que les revendications requises sont émises.
4. Autorisez les points de terminaison du fournisseur d'identité ainsi que l'application privée, sinon la redirection ne peut pas aboutir.

Le contexte du navigateur décide si une session existante du fournisseur est réutilisée. Un client natif qui ouvre le navigateur du système peut partager cet état, tandis qu'une vue intégrée avec son propre pot de cookies ne le peut généralement pas. Un nouveau navigateur, les fenêtres privées et un second profil partent de zéro, ce qui est attendu et non une configuration SSO cassée.

Exécutez le flux et lisez où il s'arrête

Reproduisez avec le panneau réseau du navigateur et observez la chaîne de redirections. Un parcours utile suit un saut à la fois : passerelle vers fournisseur, fournisseur de retour vers l'application avec un code ou une assertion, application vers le point de terminaison de jetons du fournisseur, session applicative émise. Le saut où la chaîne s'arrête nomme le composant à corriger.

Deux vérifications en ligne de commande tranchent les doutes habituels, et toutes deux peuvent être exécutées sans risque depuis un hôte d'administration :

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Lorsque les métadonnées listent des points de terminaison que vous n'avez jamais enregistrés, l'application pointe vers un autre locataire ou émetteur. Lorsque la première requête vers l'application répond 302 vers un hôte inattendu, la configuration de fédération de l'application est l'endroit à examiner, pas le profil VPN.

Corrigez les invites en trouvant qui les a demandées

Une seconde invite de mot de passe n'est pas automatiquement un défaut. L'application peut demander un niveau d'assurance plus élevé, ou le fournisseur peut imposer un âge maximal de session et un nouveau défi. Supprimer ces exigences pour rendre le flux plus silencieux affaiblit un contrôle délibéré, alors déterminez quel composant l'a demandé avant de changer la politique.

Décidez ensuite quoi améliorer. Si l'invite vient de l'application, corrigez son entrée de fédération. Si elle vient du fournisseur par politique, documentez l'exigence. Si l'application est inaccessible après une connexion réussie, le routage du tunnel est le suspect, car l'identité et l'acheminement des paquets échouent à des endroits différents et se ressemblent depuis la place de l'utilisateur.