Je ne parviens pas à me connecter avec le SSO
VaultPAM prend en charge l'authentification unique (SSO) via OpenID Connect (OIDC). Lorsque la connexion SSO échoue, la cause première relève presque toujours de l'une de ces cinq catégories : une erreur de configuration OIDC, un écart d'horloge entre VaultPAM et l'IdP, un utilisateur non provisionné dans le fournisseur d'identité, une URI de redirection incorrecte ou un paramètre de realm Keycloak. Les administrateurs doivent les passer en revue dans cet ordre — l'erreur de configuration OIDC est de loin la cause la plus fréquente.
Symptômes
- Le bouton SSO de la page de connexion redirige vers le fournisseur d'identité, mais renvoie ensuite une erreur.
- Messages d'erreur que vous pouvez rencontrer :
invalid_clientouunauthorized_clientredirect_uri_mismatchaccess_deniedinvalid_grant: Session not activeUser not foundouAccount is not fully set up- Une page générique « Une erreur s'est produite » après une redirection de retour depuis l'IdP
- L'utilisateur parvient à s'authentifier côté IdP, mais VaultPAM ne le connecte pas.
Causes
1. Erreur de configuration OIDC
L'ID client, le secret client ou l'URL de découverte OIDC configurés dans VaultPAM ne correspondent pas à ceux enregistrés par le fournisseur d'identité.
Vérification : dans Organization → Security → SSO Settings, vérifiez :
- L'OIDC Issuer URL se résout et renvoie un document
.well-known/openid-configurationvalide. - L'ID client correspond exactement à celui enregistré dans l'application de l'IdP.
- Le secret client n'a pas été renouvelé côté IdP sans mise à jour de VaultPAM.
Correction : mettez à jour le champ incohérent et enregistrez. Testez en tentant à nouveau la connexion SSO.
2. Écart d'horloge entre VaultPAM et l'IdP
Les jetons OIDC contiennent les claims iat (issued-at) et exp (expiry). Si les horloges du serveur VaultPAM ou de l'IdP présentent un écart supérieur à ±60 secondes, la validation du jeton échoue avec une erreur invalid_grant ou « Session not active ».
Vérification : sur l'hôte VaultPAM (ou le nœud Kubernetes), exécutez :
date -u
Comparez avec l'horloge de l'IdP (visible dans le claim iat d'un JWT décodé, ou vérifiée via la console d'administration de l'IdP). L'écart doit être inférieur à 60 secondes.
Correction : assurez-vous que les deux systèmes synchronisent leurs horloges sur une source NTP. Sous Linux : timedatectl set-ntp true. Dans Kubernetes, l'horloge du nœud est héritée de l'hôte de la VM — assurez-vous que la couche hyperviseur dispose d'une configuration NTP.
3. Utilisateur non provisionné dans l'IdP
Le compte de l'utilisateur existe dans VaultPAM, mais n'a pas été créé ou activé dans le fournisseur d'identité, ou l'adresse e-mail du compte IdP ne correspond pas à celle du compte VaultPAM.
Vérification : dans la console d'administration de l'IdP, confirmez que le compte utilisateur existe et est actif. Vérifiez que l'adresse e-mail correspond exactement (certains IdP appliquent une correspondance sensible à la casse).
Correction : créez ou activez le compte utilisateur dans l'IdP, ou mettez à jour l'adresse e-mail dans l'un des deux systèmes pour qu'elles correspondent. Si votre organisation utilise le provisionnement SCIM, confirmez que le connecteur de provisionnement est actif et que l'utilisateur appartient au groupe provisionné.
4. URI de redirection incorrecte
L'URI de redirection que VaultPAM envoie pendant le flux Authorization Code OIDC doit correspondre exactement à l'une des URI de redirection autorisées enregistrées dans l'application de l'IdP. Même une différence de barre oblique finale provoque une erreur redirect_uri_mismatch.
Vérification : dans Organization → Security → SSO Settings, notez la Callback URL affichée. Ouvrez l'enregistrement de l'application de l'IdP et vérifiez que cette URI exacte figure dans les URI de redirection autorisées.
Correction : ajoutez l'URL de callback exacte à la liste des URI de redirection autorisées de l'application de l'IdP et enregistrez.
5. Paramètres de realm Keycloak
Lorsque VaultPAM utilise une instance Keycloak intégrée ou auto-hébergée, des paramètres de realm mal configurés peuvent empêcher la connexion même lorsque le client OIDC est correctement configuré.
Problèmes courants spécifiques à Keycloak :
- Le realm est désactivé ou en mode lecture seule.
- L'Access Type du client est défini sur
publicalors que VaultPAM attendconfidential. - Les scopes requis
openid,emailouprofilene sont pas mappés dans le client. - Les Valid Redirect URIs du client Keycloak n'incluent pas l'URL de callback de VaultPAM.
Vérification : ouvrez la console d'administration de Keycloak, accédez à Realms → [nom du realm] → Clients → [client VaultPAM], et vérifiez :
- Le client est Enabled.
- L'Access Type est
confidential. - Les Valid Redirect URIs incluent l'URL de callback de VaultPAM.
- Les Client Scopes incluent
openid,emailetprofile.
Correction : corrigez les paramètres du client Keycloak et enregistrez. Aucun redémarrage n'est requis pour la plupart des changements de configuration Keycloak.
Étapes de résolution
- Ouvrez Organization → Security → SSO Settings et vérifiez que l'OIDC Issuer URL, l'ID client et le secret client correspondent exactement à l'enregistrement de l'application de l'IdP.
- Vérifiez les horloges des serveurs sur l'hôte VaultPAM et sur l'IdP. Si l'écart dépasse 30 secondes, configurez NTP sur les deux systèmes.
- Dans la console d'administration de l'IdP, confirmez que le compte utilisateur existe, est actif, et que l'adresse e-mail correspond à celle du compte VaultPAM.
- Confirmez que la Callback URL affichée dans Organization → Security → SSO Settings figure comme URI de redirection autorisée dans l'application de l'IdP.
- Si vous utilisez Keycloak, ouvrez la console d'administration de Keycloak et vérifiez que le client est activé, que l'access type est
confidential, que les valid redirect URIs incluent l'URL de callback et que les scopes requis sont mappés. - Après toute modification, effacez les cookies de votre navigateur et réessayez la connexion SSO depuis une fenêtre privée/navigation incognito afin d'éviter tout état de session mis en cache.
Procédure d'escalade
Si vous avez parcouru les cinq causes et que la connexion SSO échoue toujours :
- Capturez l'URL complète affichée dans la barre d'adresse du navigateur au moment de l'échec (elle contient le code d'erreur et la description sous forme de paramètres de requête).
- Récupérez le journal d'événements Keycloak ou IdP pour la tentative d'authentification échouée.
- Notez le message d'erreur exact visible à l'écran.
- Ouvrez un ticket de support en indiquant : le type et la version de votre IdP, l'URL d'erreur, l'extrait du journal d'événements, et la confirmation des étapes que vous avez déjà réalisées.