L'SSO VPN fa accedere automaticamente gli utenti alle app interne?

Un gateway VPN che si autentica tramite un provider di identità dimostra una cosa: il provider ha garantito per un utente davanti al gateway. Non consegna a quell'utente una credenziale per il wiki dell'intranet, la dashboard di monitoraggio o il server di build. Quei servizi fanno accedere le persone tramite la propria federazione e applicano la propria autorizzazione, e il tunnel decide solo quali pacchetti possono raggiungerli.

Tre sessioni, tre decisioni separate

Tenere separati gli stati, perché ciascuno scade secondo il proprio calendario. La sessione VPN è l'accettazione di un'identità da parte del gateway più l'accesso di rete che ha concesso. La sessione del browser presso il provider di identità è ciò che il browser conserva ancora per quel provider e può riutilizzare secondo la sua politica. La sessione dell'applicazione appartiene a un servizio che ha convalidato una risposta a esso indirizzata.

Confondere quegli stati produce la domanda sbagliata, di solito formulata come perché il tunnel non fa accedere l'utente ovunque. Riformulatela: quale applicazione non ha una voce di federazione, quale rifiuta l'utente e a quale manca una rotta. Un solo avviso di accesso che apre l'applicazione intranet può comunque rimbalzare al provider, perché il secondo reindirizzamento è una nuova richiesta di autorizzazione per un pubblico diverso.

Collegare il gateway come applicazione a sé

Registrare la VPN come applicazione approvata presso il provider, con il proprio identificatore, URI di reindirizzamento e assegnazione degli utenti. Poi decidere quali autorizzazioni di rete concede quell'accesso, poiché è una politica VPN e non una funzione del provider. Gli utenti che devono raggiungere solo la sottorete di monitoraggio ricevono una politica del gateway diversa, non una password diversa.

La risposta di autenticazione del tunnel non è una credenziale riutilizzabile. I token ID di OIDC portano un'attestazione di pubblico che nomina il client per cui sono stati emessi, e le asserzioni portanti SAML limitano il pubblico al provider di servizio ricevente. Un secondo servizio che accetta la risposta del primo è configurato male, e copiare un token in un'altra applicazione non è integrazione.

Registrare ogni applicazione interna, poi impostare il contesto del browser

Ogni servizio ha bisogno dei valori SAML o OIDC supportati: emittente, identificatore client, URL di callback o di consumatore di asserzioni, attestazioni richieste e assegnazione. La raggiungibilità si aggiunge, perché i controlli di identità non forniscono mai una rotta o una risposta DNS.

1. Creare la voce dell'applicazione e confermare che l'ID entità o client corrisponda a ciò che l'applicazione invia.
2. Registrare l'URL di callback esatto, incluso schema e porta; un errore minimo fallisce dopo che l'utente si è autenticato.
3. Assegnare gli utenti o i gruppi, poi confermare che le attestazioni richieste vengono rilasciate.
4. Consentire gli endpoint del provider di identità oltre all'applicazione privata, altrimenti il reindirizzamento non può completarsi.

Il contesto del browser decide se una sessione esistente del provider viene riutilizzata. Un client nativo che apre il browser di sistema può condividere quello stato, mentre una vista incorporata con il proprio barattolo di cookie di solito non può. Nuovo browser, finestre private e un secondo profilo partono da zero, il che è atteso e non una configurazione SSO rotta.

Eseguire il flusso e leggere dove si ferma

Riprodurre con il pannello di rete del browser e osservare la catena di reindirizzamenti. Un percorso utile segue un salto alla volta: gateway verso provider, provider di ritorno all'applicazione con un codice o un'asserzione, applicazione verso l'endpoint dei token del provider, sessione dell'applicazione emessa. Il salto in cui la catena si ferma nomina il componente da correggere.

Due controlli da riga di comando risolvono i dubbi abituali, ed entrambi sono sicuri da eseguire da un host amministrativo:

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:)'

Quando i metadati elencano endpoint che non hai mai registrato, l'applicazione punta a un altro tenant o emittente. Quando la prima richiesta all'applicazione risponde 302 verso un host inatteso, la configurazione di federazione dell'applicazione è il punto da esaminare, non il profilo VPN.

Correggere gli avvisi trovando chi li ha chiesti

Un secondo avviso di password non è automaticamente un difetto. L'applicazione può richiedere un livello di garanzia più alto, oppure il provider può imporre un'età massima della sessione e una nuova verifica. Rimuovere quei requisiti per rendere il flusso più silenzioso indebolisce un controllo deliberato, quindi stabilire quale componente li ha chiesti prima di cambiare la politica.

Poi decidere cosa migliorare. Se l'avviso viene dall'applicazione, correggere la sua voce di federazione. Se viene dal provider per politica, documentare il requisito. Se l'applicazione non è raggiungibile dopo un accesso riuscito, il routing del tunnel è il sospetto, perché identità e consegna dei pacchetti falliscono in punti diversi e appaiono simili dal posto dell'utente.