Il fulcro dell’autenticazione Single Sign-On è una tecnologia denominata JSON Web Token (JWT) che consente a Zendesk di considerare attendibili le richieste di accesso ricevute dai sistemi. Per maggiori dettagli, consultaConfigurazione di Single Sign-On con JWT (JSON Web Token) .
Non inserire il JWT direttamente nell’URL in quanto gli URL possono essere potenzialmente esposti a utenti malintenzionati tramite i registri del server, la cronologia del browser e gli intermediari di rete.
Per le integrazioni SSO Zendesk, un meccanismo lato server dovrebbe generare il JWT e reindirizzare il browser dell’utente a un URL specifico di Zendesk, passando il JWT come parametro nella stringa di query anziché nell’intestazione HTTP.
Un JWT in genere è composto da tre parti separate da punti (punti). Ogni parte ha uno scopo diverso all'interno della struttura JWT: intestazione, payload e firma.
Blocco 1: Intestazione JWT
Il primo blocco è l'intestazione JWT. Indica che si tratta di una richiesta JWT e indica il tipo di algoritmo di hashing usato. (Ne parleremo più avanti.)
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
La grande rivelazione di questo (e del resto dei dati) è che è codificato in base64. Questa non è in realtà una crittografia, quindi può essere facilmente decodificata da strumenti come i seguenti:
- Strumento web:http://www.base64decode.org/
- Terminale:http://drewsymo.com/how-to/quick-and-simple-base64-encode-on-mac-osx-terminal/
Ecco come appare la stringa decodificata:
{"typ":"JWT",
"alg":"HS256"}
Puoi vedere che richiede una struttura JSON e ha due coppie chiave-valore che in effetti significano type: JWT e Algorithm: HMAC SHA 256. SHA 256 è un algoritmo di crittografia a 256 bit progettato dagli Stati Uniti NSA (National Security Agency, Agenzia per la Sicurezza Nazionale degli Stati Uniti) Viene usato per generare il terzo blocco, la firma, di cui parleremo tra poco.
Blocco 2: Set di attestazioni JWT/Carico utile
Il secondo blocco è notevolmente più lungo perché contiene il payload. È noto come “Insieme di attestazioni JWT”.
eyJpYXQiOjEzNzIxMTMzMDUsImp0aSI6ODg4MzM2MjUzMTE5Ni4zMjYsIm5hbWUiOiJUZXN0IFVzZXIiLCJlbWFpbCI6InR1c2VyQGV4YW1wbGUub3JnIiwiZXh0ZXJuYWxfaWQiOiI1Njc4Iiwib3JnYW5pemF0aW9uIjoiQXBwbGUiLCJ0YWdzIjoidmlwX3VzZXIiLCJyZW1vdGVfcGhvdG9fdXJsIjoiaHR0cDovL21pdC56ZW5mcy5jb20vMjA2LzIwMTEvMDUvQmFybmFieV9NYXR0X2Nyb3BwZWQuanBnIiwibG9jYWxlX2lkIjoiOCJ9
Contiene una data/ora, un valore casuale, un nome utente, un indirizzo email, un ID esterno e alcuni tag. Sono disponibili ancora più opzioni. Ancora una volta, è sufficiente decodificarlo in base64 per dare un senso al payload. Divido le linee per semplificare la digestione.
{
"iat":1372113305,
"jti":8883362531196.326,
"name":"Test User",
"email":"tuser@example.org",
"external_id":"5678",
"organization":"Apple",
"tags":"vip_user",
"remote_photo_url":"http://mit.zenfs.com/206/2011/05/Barnaby_Matt_cropped.jpg",
"locale_id":"8"
}
Obbligatorio
IAT
La prima chiave èiat, che sta peremesso alle. Si tratta di un timestamp formattato in secondi interi dal 1 gennaio 1970, che è una rappresentazione UNIX standard dell’ora. Il timestamp deve essere un numero intero (senza decimali) e deve essere in formato UTC. Inoltre, deve essere entro 3 minuti dall’ora corrente in cui il server Zendesk lo riceve. In questo modo, ogni richiesta di autenticazione remota si autodistrugge, impedendo che ogni singola richiesta venga usata dopo più di 3 minuti dalla generazione.
JTI
La seconda chiave,jti, sta perJSON Token ID. In realtà è solo una stringa casuale. Deve essere sufficientemente lungo e casuale in modo che sia molto improbabile che venga usato di nuovo su questo account. Se, per errore o per caso, viene riutilizzato per un'altra richiesta di autenticazione, la richiesta non avrà esito positivo. Ciò che equivale a una chiave usa e getta. Includendo un valore casuale (obbligatorio) come questo, garantiamo che non ci siano due richieste di autenticazione uguali. Ciò impedisce il riutilizzo di un URL di richiesta valido. Ad esempio, immagina che qualcuno sia riuscito a installare malware sul tuo computer o sulla tua rete e abbia iniziato a registrare il tuo traffico. Possono vedere tutti gli URL che trovi. Se vedono e recuperano l’URL che ti è stato assegnato per accedere a Zendesk, potrebbero usarlo per accedere come te entro 3 minuti senza questa chiave monouso.
Nome
Il prossimo è ilnomecompleto dell’utente con spazi inclusi. Qualsiasi cosa Zendesk riceve qui viene impostato come nome utente, anche se in precedenza era impostato un nome diverso.
Dopo quella è l’indirizzo email dell’utente. Viene usato come identificatore univoco per un utente, ameno che non venga ricevuto un ID esterno*. Ciò significa che se riceviamo un’email e un ID esterno, cerchiamo prima di abbinare l’ID. In tal caso, aggiorniamo l’utente con l’indirizzo email specificato.
*Nota: Se l’opzione “Consenti aggiornamento di ID esterni” è abilitata in Zendesk, continueremo a disattivare l’email anche se viene ricevuto un ID esterno. Se l’indirizzo email e l’ID esterno differiscono, cambieremo l’ID.
Opzionale
ID esterno
L’ID esterno è un ID facoltativo che puoi usare per identificare gli utenti anziché usare il loro indirizzo email (come indicato sopra).
Organizzazione
Puoi anche passare un valore diorganizzazioneper aggiungere un utente a un’organizzazione. L’organizzazione denominata deve esistere già e il nome deve corrispondere esattamente. In caso contrario, non verrà eseguita alcuna azione.
Tag
La chiave tagconsente di impostare i tag sull’utente che ha effettuato l’accesso. La chiave sostituisce tutti i tag esistenti nell’utente con i tag specificati, quindi usala con attenzione. Il passaggio di un parametro tag vuotorimuove tutti i tag da un utente.
URL foto remota
Puoi anche passare un valore per remote_photo_url, che accetta un URL pubblico contenente una foto e imposta questa foto come immagine del profilo dell’utente.
Impostazioni locali (lingua)
Puoi passare un valore perlocale_id per impostare o aggiornare la lingua dell’utente autenticato in Zendesk. Il valore deve essere un numero che corrisponde a una lingua attualmente attivata in Zendesk. Puoi trovare le impostazioni locali usando l’endpoint locales.json della nostra API: https://developer.zendesk.com/api-reference/ticketing/account-configuration/locales/#list-locales
Campi utente (non mostrati nell’esempio)
Deve essere un oggetto JSON che include coppie chiave-valore per ogni chiave e valore di campo. La chiave del campo può essere trovata o definita nell’interfaccia Campi utente. Tieni presente che possono essere inoltrati solo campi utente personalizzati.
Esempio:
"user_fields": {"checked": false,"date_joined": "2013-08-14T00:00:00+00:00","region": "EMEA","text_field": null}
Le caselle di spunta usano valori booleani, i codici data seguono l’esempio qui sopra e i menu a discesa accettano il nome dell’opzione. I campi di testo accettano stringhe.
Numero di telefono (non mostrato nell’esempio)
Accetta una stringa per l’identità di un numero di telefono. Assicurati di specificare il numero di telefono in un formato accettato. Per maggiori informazioni, consultaQuali sono i formati accettati per i numeri di telefono?
Blocco 3: Firma JWS
L’ultimo blocco della richiesta è la parte crittografata. Non devi preoccuparti troppo di questo, ma in pratica prende tutte le informazioni sopra (iat, jti, nome, email, ecc.) Insieme alsegreto condivisoe genera una stringa crittografata. Quindi, in base agli standard JWT, viene presa una parte di quella stringa crittografata (nota come checksum), ovvero la firma JWS.
Quindi, in che modo è sicuro?
Per generare una stringa crittografata valida, devi conoscere ilsegreto condiviso.
La crittografia è progettata in modo da non poter tornare indietro dalla stringa crittografata ai dati e alla chiave. Anche se disponi del contenuto dei dati, è praticamente impossibile dedurre la chiave.
Ma poiché tu hai la chiave, e noi la chiave, e tu ci invii gli stessi dati non crittografati che ci invii crittografati, possiamo creare noi stessi la firma e verificare che corrisponda a ciò che hai inviato.
Inoltre, garantisce che nessuno possa manomettere i dati in transito.
Questo è il modo in cui lo si compila in pseudo-codice:
URLBase64Encode(
HMAC-SHA256(
URLBase64Encode( header_json ).URLBase64Encode( payload_json )
)
)
Quando si genera il codice HMAC-SHA256 dell’intestazione e del payload codificati, includi il segreto condiviso.
Questo è il risultato:
Zv9P7PNIcgHfxZaMwQtMpty3TZnmVHRWcsmAMM-mNHg
Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.
Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.