Per impostazione predefinita, il servizio di account accessibile esternamente di Google gestisce l'autenticazione per gli account Google. Quando un utente non autenticato visita una pagina Google che richiede l'autenticazione, il modulo di accesso Google richiede l'indirizzo email e la password dell'utente. Dopo che l'utente ha inviato l'email e la password, l'autenticazione Google verifica che le credenziali inserite siano corrette. Se le credenziali sono corrette, l'autenticazione Google imposta i cookie di accesso dell'utente.
Alcune aziende utilizzano un modello più sofisticato in cui l'autenticazione viene gestita da un provider di identità di terze parti (IdP). L'autenticazione Google supporta questo modello tramite il protocollo SAML (Security Assertion Markup Language) standard del settore. Un amministratore può configurare un dominio per utilizzare l'autenticazione SAML.
Ottenere la password dell'utente
ChromeOS deve identificare la password inserita dall'utente durante l'accesso per:
- Cripta i dati dell'utente archiviati sull'unità disco.
- Proteggere la schermata di blocco.
- Attiva l'accesso offline quando non è disponibile una rete.
Quando si utilizza SAML, la password non viene inserita direttamente in una finestra di dialogo di sistema di ChromeOS, ma all'interno di una webview ospitata dal provider di identità. Sebbene ChromeOS abbia accesso all'HTML, non esiste un modo semplice e canonico per ottenere la password, in quanto non è chiaro quali campi del modulo contengano i dati.
Esistono due modi per ottenere la password di un utente quando utilizzi SAML: l'API Credentials Passing e lo scraping delle password.
API Chrome Credentials Passing
Google fornisce un'API Credentials Passing che i provider di identità possono implementare nelle pagine SAML, in JavaScript, per trasferire i dati richiesti a ChromeOS. L'autenticazione Google utilizza questa API, ma potrebbe essere utilizzata anche da qualsiasi provider di identità SAML.
Scraping delle password
Un provider di identità SAML può utilizzare lo scraping delle password quando non supporta l'API Credentials Passing.
Con questo metodo:
- La schermata di autenticazione inserisce uno script di contenuti nella webview che ospita la procedura di accesso.
- Il content script identifica i campi di input HTML di tipo password e ne copia i contenuti in un array. L'array viene aggiornato ogni volta che cambiano i contenuti di un campo password.
- Le password sottratte vengono inviate a una pagina in background che le accumula. In questo modo, la password può essere acquisita anche se il flusso di accesso si estende su più reindirizzamenti a pagine HTML diverse.
Al termine del flusso di accesso, l'array di password sottoposte a scraping viene recuperato dalla pagina in background. Sono possibili tre casi: non è stata eseguita alcuna operazione di scraping della password, è stata eseguita l'operazione di scraping di una sola password o di più password.
Nessuna password è stata estratta
Lo script dei contenuti non riesce a trovare la password nelle pagine HTML pubblicate dal provider di identità. Il provider di identità potrebbe non utilizzare password tradizionali.
In questo scenario, ChromeOS chiederà all'utente di scegliere una password manuale per il dispositivo. Se la password non esiste (ad es. autenticazione tramite smart card, NFC, biometria), la procedura di autenticazione di ChromeOS può procedere senza la password.
È stata eseguita la scansione di una sola password
Il content script identifica esattamente una password. Molto probabilmente, si tratta della password dell'utente utilizzata per l'autenticazione.
In questo scenario, è molto probabile che abbiamo eseguito lo scraping della password dell'utente correttamente. ChromeOS utilizzerà la password estratta come password dell'utente per continuare la procedura di autenticazione.
È stata eseguita la raccolta di più di una password
Il content script identifica più password. Ciò può accadere in circostanze come un provider di identità che richiede a un utente di inserire una password permanente e una password monouso nel modulo di accesso.
In questo scenario, probabilmente abbiamo eseguito lo scraping della password effettiva dell'utente e di alcuni campi password aggiuntivi che non interessano ChromeOS. Per determinare quale sia la password corretta, ChromeOS chiederà all'utente di inserirla un'altra volta in un ulteriore prompt della password.
Se la password inserita corrisponde a una delle password recuperate, la password effettiva dell'utente è stata identificata e la procedura di autenticazione continuerà. Se non viene trovata alcuna corrispondenza, all'utente verrà chiesto di inserire nuovamente la password. Dopo due tentativi non riusciti, l'accesso non riesce e viene visualizzato un messaggio di errore.
Registrazione aziendale
Per la registrazione aziendale, l'indirizzo email dell'utente che esegue la registrazione è necessario per associare il dispositivo al dominio corretto. L'email viene inviata dal server di gestione dei dispositivi (DM) a Chrome nel campo del nome utente del messaggio PolicyData durante il recupero dei criteri del dispositivo. Non è necessario determinare la password dell'utente.