Non riesco ad accedere con SSO
VaultPAM supporta il Single Sign-On (SSO) tramite OpenID Connect (OIDC). Quando l'accesso SSO non riesce, la causa radice è quasi sempre una di cinque categorie: errore di configurazione OIDC, sfasamento dell'orologio tra VaultPAM e l'IdP, utente non provisioning nel Provider di Identità, URI di reindirizzamento errato, o impostazione di realm Keycloak. Gli amministratori devono esaminarle in ordine — l'errore di configurazione OIDC è di gran lunga la causa più comune.
Sintomi
- Il pulsante SSO nella pagina di accesso reindirizza al Provider di Identità ma poi restituisce un errore.
- Messaggi di errore che potresti visualizzare:
invalid_clientounauthorized_clientredirect_uri_mismatchaccess_deniedinvalid_grant: Session not activeUser not foundoAccount is not fully set up- Una pagina generica "Something went wrong" dopo un reindirizzamento di ritorno dall'IdP
- L'utente può autenticarsi lato IdP ma VaultPAM non lo accede.
Cause
1. Errore di configurazione OIDC
L'ID Client, il Segreto Client o l'URL di discovery OIDC configurati in VaultPAM non corrispondono a quello che il Provider di Identità ha registrato.
Verifica: In Organization → Security → SSO Settings, conferma:
- OIDC Issuer URL si risolve e restituisce un documento
.well-known/openid-configurationvalido. - Client ID corrisponde esattamente a quello registrato nell'applicazione IdP.
- Client Secret non è stato ruotato lato IdP senza aggiornare VaultPAM.
Soluzione: Aggiorna il campo non corrispondente e salva. Verifica tentando di nuovo l'accesso SSO.
2. Sfasamento dell'orologio tra VaultPAM e l'IdP
I token OIDC contengono claim iat (issued-at) e exp (expiry). Se gli orologi sul server VaultPAM o sull'IdP differiscono di più di ±60 secondi, la convalida del token fallisce con un errore invalid_grant o "Session not active".
Verifica: Sull'host VaultPAM (o nodo Kubernetes), esegui:
date -u
Confronta con l'orologio dell'IdP (visibile nel claim iat di un JWT decodificato, o verificabile tramite la console admin IdP). La differenza deve essere inferiore a 60 secondi.
Soluzione: Assicurati che entrambi i sistemi sincronizzino i loro orologi rispetto a un'origine NTP. Su Linux: timedatectl set-ntp true. In Kubernetes, l'orologio del nodo viene ereditato dall'host della VM — assicurati che il layer dell'hypervisor abbia NTP configurato.
3. Utente non provisioning nell'IdP
L'account dell'utente esiste in VaultPAM ma non è stato creato o attivato nel Provider di Identità, oppure l'email dell'account IdP non corrisponde all'email dell'account VaultPAM.
Verifica: Nella console admin IdP, conferma che l'account utente esista e sia attivo. Verifica che l'indirizzo email corrisponda esattamente (in alcuni IdP si applica un confronto sensibile alle maiuscole).
Soluzione: Crea o attiva l'account utente nell'IdP, oppure aggiorna l'indirizzo email in uno dei due sistemi per assicurarti che corrispondano. Se la tua organizzazione utilizza il provisioning SCIM, conferma che il connettore di provisioning sia attivo e che l'utente appartenga al gruppo sottoposto a provisioning.
4. URI di reindirizzamento errato
L'URI di reindirizzamento che VaultPAM invia durante il flusso Authorization Code OIDC deve corrispondere esattamente a uno degli URI di reindirizzamento consentiti registrati nell'applicazione IdP. Anche una differenza di slash finale causa un errore redirect_uri_mismatch.
Verifica: In Organization → Security → SSO Settings, nota l'URL di Callback visualizzato. Apri la registrazione dell'applicazione IdP e verifica che questo URI esatto sia elencato negli URI di reindirizzamento consentiti.
Soluzione: Aggiungi l'URL di callback esatto all'elenco degli URI di reindirizzamento consentiti dell'applicazione IdP e salva.
5. Impostazioni di realm Keycloak
Quando VaultPAM utilizza un'istanza Keycloak incorporata o self-hosted, le impostazioni di realm non configurate correttamente possono impedire l'accesso anche quando il client OIDC è configurato correttamente.
Problemi specifici di Keycloak comuni:
- Il realm è disabilitato o in modalità sola lettura.
- L'Access Type del client è impostato su
publicquando VaultPAM si aspettaconfidential. - Gli ambiti obbligatori
openid,emailoprofilenon sono mappati nel client. - Gli URI di Reindirizzamento Validi nel client Keycloak non includono l'URL di callback di VaultPAM.
Verifica: Apri la console admin Keycloak, vai a Realms → [nome realm] → Clients → [client VaultPAM], e verifica:
- Il client sia Enabled.
- L'Access Type sia
confidential. - Gli URI di Reindirizzamento Validi includano l'URL di callback di VaultPAM.
- Gli Ambiti Client includano
openid,emaileprofile.
Soluzione: Correggi le impostazioni del client Keycloak e salva. Non è richiesto alcun riavvio per la maggior parte delle modifiche di configurazione di Keycloak.
Passaggi di risoluzione
- Apri Organization → Security → SSO Settings e verifica che l'OIDC Issuer URL, l'ID Client e il Segreto Client corrispondano esattamente alla registrazione dell'applicazione IdP.
- Controlla gli orologi del server sull'host VaultPAM e sull'IdP. Se lo sfasamento supera 30 secondi, configura NTP su entrambi i sistemi.
- Nella console admin IdP, conferma che l'account utente esista, sia attivo e che l'email corrisponda all'email dell'account VaultPAM.
- Conferma che l'URL di Callback mostrato in Organization → Security → SSO Settings sia elencato come URI di reindirizzamento consentito nell'applicazione IdP.
- Se utilizzi Keycloak, apri la console admin Keycloak e verifica che il client sia abilitato, il tipo di accesso sia
confidential, gli URI di reindirizzamento validi includano l'URL di callback e gli ambiti richiesti siano mappati. - Dopo qualsiasi modifica, cancella i cookie del browser e riprova l'accesso SSO da una finestra privata/in incognito per evitare lo stato della sessione memorizzato nella cache.
Percorso di escalation
Se hai esaminato tutte e cinque le cause e l'accesso SSO continua a fallire:
- Acquisisci l'URL completo mostrato nella barra degli indirizzi del browser al momento del guasto (contiene il codice di errore e la descrizione come parametri di query).
- Raccogli il registro degli eventi Keycloak o IdP per il tentativo di autenticazione non riuscito.
- Nota il messaggio di errore esatto visibile sullo schermo.
- Apri un ticket di supporto con: il tipo e la versione del tuo IdP, l'URL dell'errore, lo snippet del registro degli eventi e la conferma dei passaggi che hai già completato.