Token di accesso personali e JWT di Connected App, e quando ciascuno è quello giusto

Due credenziali, due lavori

Token di accesso personale

Emesso a una persona, a suo nome, con esattamente i suoi permessi e niente di più. È una credenziale di accesso, e risponde alla domanda: chi è questo.

Connected App, fiducia diretta

Configurata una volta per sito da un amministratore. Il server ne conia JWT di breve durata che attestano un account di servizio con un nome. È un’estensione di capacità, e risponde a una domanda diversa: cosa può fare questa capacità della piattaforma, e per quale account.

Sono due strade verso due posti diversi. Trattarle come intercambiabili è l’errore di credenziale con più conseguenze in un’integrazione Tableau. L’errore è comune, perché funzionano entrambe.

Perché vince il token personale

La regola qui è scritta nel codice, e dichiarata nel modulo che la implementa. Ogni utente accede con il proprio token Tableau. Quel token porta i suoi esatti permessi Tableau. È il confine di governance per ogni lettura, ogni scrittura, e ogni chiamata di assistente o strumento fatta per suo conto.

L’accesso appartiene solo al token personale. Un percorso a un clic che lo saltava è esistito a un certo punto, ed è stato ritirato deliberatamente. Il resolver è stato rimosso, e il gateway ora rifiuta un tentativo di connessione a forma di JWT.

La ragione è pratica più che architetturale. Lascia che una credenziale di servizio faccia accedere una persona, e ogni azione successiva porta i permessi dell’account di servizio invece di quelli della persona. Il modello di permessi Tableau che il tuo team ha impiegato anni a costruire smette allora di decidere chi può vedere cosa.

Cosa fa la Connected App

Copre una capacità della piattaforma: una persona ha già effettuato l’accesso, e la piattaforma stessa ha bisogno di un token proprio. L’incorporamento è l’esempio vivo. Una vera vista Tableau renderizzata dentro un’altra superficie ha bisogno di un token che l’API di incorporamento accetti, e un token personale ha la forma sbagliata per questo.

• ID client, ID del secret e valore del secret vengono bloccati per sito Tableau da un amministratore, cifrati a riposo, e mai restituiti a un browser.
• Il token viene coniato lato server e limitato per dominio. È di breve durata per progettazione, perché un token di servizio di lunga durata è una concessione permanente che nessuno rivede.
• Il JWT attesta un account di servizio Tableau con un nome: ciò che può raggiungere è ciò che quell’account può raggiungere. Dagli un ruolo ampio e gli hai dato un ruolo ampio.

Tenere puliti i token personali

• Un token per persona per l’uso interattivo. È la sua identità dentro il prodotto, e condividerlo distrugge ogni attribuzione a valle.
• Un token separato e dedicato per qualsiasi automazione. Tableau consente una sola sessione attiva per token. Un’automazione che riusa il token interattivo di qualcuno farà uscire quella persona dalla propria sessione, di solito a un’ora scomoda.
• Dai a un token il nome del suo scopo, non del suo creatore. Entro un anno il creatore ha cambiato ruolo e lo scopo no.
• Ruota a una cadenza che manterrai davvero, e metti la scadenza in un calendario invece di scoprirla.

Il secondo punto produce ticket di supporto che sembrano instabilità del prodotto. Sono una collisione di credenziali. Vale la pena verificarlo per primo ogni volta che un job pianificato e una persona sembrano interferire tra loro.

L’unica eccezione deliberata

I segreti in questa suite durano solo per la sessione. Questo regge bene finché qualcosa non deve girare alle due di notte senza nessuno connesso. Un segreto di sessione non può esistere a quell’ora, per definizione.

C’è un’eccezione, ed è esplicita anziché implicita. Un operatore clicca per bloccare un token per le esecuzioni pianificate. È cifrato a riposo sotto una chiave della macchina, mai registrato nei log, e mai restituito al browser. La chiamata di descrizione restituisce solo il nome del token. Un clic lo rimuove. L’interfaccia consiglia un token di automazione dedicato, per la ragione della collisione descritta sopra.

Un’eccezione su cui una persona deve cliccare è un’eccezione che qualcuno può ritrovare dopo. Un’eccezione che avviene automaticamente è una che nessuno può verificare, e alla fine una a cui nessuno ricorda di aver acconsentito.

Dichiara quale credenziale ha risposto

Un job pianificato può provare prima un token personale e ripiegare su un JWT di Connected App. È una progettazione sensata. Può anche nascondere una credenziale rotta per mesi, perché dall’esterno l’esecuzione continua a riuscire.

La correzione è piccola e conta. Registra quale credenziale ha davvero autenticato, e mostrala sulla riga. Un ripiego che avviene in modo invisibile è un ripiego che nessuno ripara mai. La prima volta che qualcuno ne sente parlare è il giorno in cui fallisce anche il ripiego.

Scegliere, in quattro verifiche

1. Una persona specifica sta facendo questo, adesso, davanti a uno schermo. Il suo token.
2. Una capacità della piattaforma ha bisogno di un token proprio mentre una persona è presente. La Connected App.
3. Gira senza nessuno presente. Un token di automazione dedicato, bloccato deliberatamente, invece di quello interattivo di una persona.
4. Una parte di questo ha bisogno di permessi che appartengono a qualcuno diverso dalla persona che chiede. Fermati lì. Quella è la verifica che trasforma un confine di governance in un suggerimento.

Quattro verifiche, e la quarta è quella su cui vale la pena andare piano. Tutto il resto in questa pagina dipende dal farla bene.