Supporto per il Single sign-on
Introduzione
Il reindirizzamento del contenuto del browser offre ora un’esperienza utente semplificata con il supporto per il single sign-on, consentendo l’autenticazione lato VDA e la condivisione dei cookie.
Questo miglioramento elimina gli accessi ridondanti, aumentando la produttività mantenendo l’autenticazione e la persistenza dei cookie tra le sessioni BCR, anche dopo la chiusura della finestra BCR.
Questa esperienza senza interruzioni migliora ulteriormente la sicurezza garantendo che l’autenticazione provenga dal VDA, non dal client.
Senza Single sign-on
- L’apertura di una pagina autenticata all’interno di BCR richiedeva agli utenti di reinserire le proprie credenziali ogni volta, interrompendo la persistenza dell’SSO.
- L’SSO veniva mantenuto solo mentre la finestra BCR rimaneva aperta; la chiusura e la riapertura della finestra costringevano gli utenti a ripetere il processo di accesso.
- Il flusso di autenticazione avveniva dal client, costringendo gli amministratori a fornire l’accesso alla rete a siti di autenticazione sicuri dal dispositivo client.
Con Single sign-on
- Agli utenti non vengono più richieste le credenziali (se già autenticati sul VDA), poiché l’SSO viene mantenuto senza interruzioni dal browser VDA.
- L’autenticazione avviene dal VDA, il che migliora la postura di sicurezza limitando i requisiti di rete lato client e l’esposizione, fornendo un’esperienza significativamente migliorata e ininterrotta.
Requisiti minimi
- Citrix App e Desktop Virtuali 2507
- Citrix Workspace App per Windows 2511
- Citrix Workspace App per Linux 2601
- Estensione di reindirizzamento del browser (Chrome o Edge) 25.11 o versioni successive
Sequenze di autenticazione supportate
Esistono due tipi di sequenze di autenticazione attualmente supportate con il Single sign-on BCR.
Autenticazione basata su reindirizzamento
In questo metodo standard, l’applicazione utilizza un reindirizzamento HTTP per forzare l’utente a una pagina dedicata per l’autenticazione.
Ad esempio, se un utente tenta di raggiungere https://my.intranet.app senza i cookie di sessione necessari, l’applicazione web risponderà con un reindirizzamento HTTP 302 all’endpoint di autenticazione, come https://my.intranet.app/auth .
Una volta che l’utente si autentica correttamente su quella pagina, il browser viene reindirizzato all’URL originale dell’applicazione, ora includendo i cookie di autenticazione richiesti.
Autenticazione basata su moduli nella pagina [Preview]
Questo metodo mantiene l’utente sull’URL dell’applicazione previsto mentre presenta dinamicamente l’interfaccia di accesso.
Ad esempio, se un utente naviga a una pagina protetta, come https://my.intranet.app , la pagina carica direttamente il modulo di autenticazione senza attivare un reindirizzamento, perché i cookie necessari sono mancanti. Questo processo può comportare diversi scambi interni tra l’interfaccia della pagina e il provider di identità (IDP). Questi scambi continuano finché non viene fornito e utilizzato un cookie finale valido, concedendo all’utente l’accesso al contenuto della pagina originale.
Nota:
Nel caso in cui il tuo scenario non sia coperto dai meccanismi specificati sopra e non sia possibile configurare la tua webapp per utilizzare i meccanismi sopra indicati, contatta il team di prodotto Citrix.
Configurazione
Passaggio 0: Introduzione
Esistono due metodi per configurare il Single sign-on con BCR. La scelta del metodo di configurazione dipende dal meccanismo di autenticazione per i siti web BCR desiderati e dalla flessibilità necessaria per configurare più applicazioni web per il supporto del single sign-on.
Metodo 1: Questo metodo utilizza le policy BCR esistenti in Web Studio e le impiega per ottenere il supporto del Single sign-on.
Prima dell’introduzione del supporto per il Single sign-on, la policy dei siti di autenticazione per il reindirizzamento del contenuto del browser veniva utilizzata per specificare gli URL impiegati per l’autenticazione (o le pagine intermedie) da reindirizzare al client per garantire che non ci fossero interruzioni nel flusso.
Con l’introduzione del supporto per il Single sign-on, BCR sfrutterà i cookie di autenticazione nel browser lato VDA e, di conseguenza, gli URL nella policy dei siti di autenticazione devono ora essere configurati nella policy della lista di blocco del reindirizzamento del contenuto del browser. Ciò garantisce che l’autenticazione avvenga tramite il VDA.
Metodo 2: Questo metodo opera con una logica simile al Metodo 1, ma gli URL vengono configurati tramite JSON (bcrconfig.json) e l’URL JSON ospitato viene richiamato nella policy ACL di BCR. La configurazione JSON offre ulteriore flessibilità.
- Le aziende utilizzano diverse applicazioni web nel loro ambiente e ogni applicazione può utilizzare un meccanismo di autenticazione diverso in base alla sua implementazione. Il nuovo metodo JSON consente una configurazione più intuitiva, robusta e scalabile.
- Quando si tratta di autenticazione basata su moduli in-page, il Metodo 1 non offre un modo per impostare cookie di autenticazione specifici poiché non esistono policy per supportare tale configurazione. Pertanto, se il tuo sito web richiede l’autenticazione basata su moduli in-page, JSON è l’unico modo per farlo.
Guardando al futuro, JSON offre un modo scalabile per introdurre funzionalità più robuste e Citrix consiglia di provare la configurazione basata su JSON.
Passaggio 1: Determinazione del meccanismo di autenticazione
Per determinare quale Metodo utilizzare per la configurazione, il primo passaggio è stabilire quale tipo di meccanismo di autenticazione sta utilizzando l’applicazione. Per determinare con precisione il metodo di autenticazione dell’applicazione web, l’approccio migliore è contattare l’amministratore dell’applicazione web.
Se non è possibile, è necessario ispezionare le interazioni richiesta/risposta negli strumenti per sviluppatori del browser, nella scheda Rete, durante l’esecuzione del flusso di autenticazione senza l’estensione BCR installata. I seguenti risultati possono aiutarti a determinare il tipo di autenticazione:
Per l’autenticazione basata su reindirizzamento: Cerca nella colonna Stato una o più risposte 302 (Reindirizzamento). Le risposte 302 dovrebbero contenere un’intestazione di posizione che punta alla pagina di autenticazione. Questo URL della pagina deve essere impostato nella policy della lista di blocco del reindirizzamento del contenuto del browser se si utilizza il Metodo 1 e nella sezione denyList della configurazione dell’app nel file bcrconfig.json se si utilizza il Metodo 2.
Per l’autenticazione basata su moduli in-page: Cerca nella colonna Metodo diverse richieste POST. Una delle risposte successive a una richiesta POST dovrebbe restituire un’intestazione set-cookie con il cookie di autenticazione specifico dell’applicazione web. Questo cookie dovrebbe essere impostato nella sezione dei cookie della configurazione dell’app nel file bcrconfig.json. Poiché il Metodo 1 non supporta l’autenticazione basata su moduli in-page, il Metodo 2 è l’unica opzione di configurazione per questo scenario.
Esempio: Ecco un esempio con github.com. Questo metodo può essere utilizzato per qualsiasi sito web che si desidera reindirizzare con BCR e per assicurarsi di avere la configurazione corretta.
- Apri Chrome, quindi premi CTRL+MAIUSC+I per aprire gli strumenti per sviluppatori.
- Fare clic sulla scheda Network.
- Selezionare l’impostazione Preserve log.
- Fare clic sul filtro Doc per semplificare i log di rete.
- Fare clic con il pulsante destro del mouse accanto a Name e aggiungere la colonna URL.
- Accedere a github.com mentre gli strumenti per sviluppatori sono ancora aperti.
- Accedere a github.com
- Annotare tutti i passaggi intermedi tra la pagina iniziale di github.com e la sua destinazione dopo che è avvenuto l’accesso.
- Analizzare le intestazioni di richiesta/risposta per determinare il tipo di autenticazione come specificato sopra.
Passaggio 2: Scegliere un metodo di configurazione
-
Se si gestisce solo l’autenticazione basata su reindirizzamento e non si ha la necessità di reindirizzare più applicazioni web con esigenze diverse (ad esempio, un’applicazione web con autenticazione basata su reindirizzamento e un’altra applicazione web con autenticazione basata su moduli nella pagina), è possibile scegliere il Metodo 1 per configurare il Single sign-on.
-
Se si gestisce l’autenticazione basata su moduli nella pagina (o) si gestiscono più applicazioni web con meccanismi di autenticazione diversi (o) si desidera semplicemente maggiore flessibilità anche se si dispone solo di autenticazione basata su reindirizzamento, è possibile scegliere il Metodo 2.
Passaggio 3: Configurare
Metodo 1: Configurare il Single sign-on BCR con le policy esistenti
- Abilitare la funzionalità nel VDA creando il seguente valore di registro in
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1 - Configurare la policy di configurazione ACL per il reindirizzamento del contenuto del browser con i siti web da reindirizzare. Nessuna modifica alla configurazione su questo fronte.
- Nel caso in cui siano già stati configurati URL nel criterio dei siti di autenticazione, copiarli nel criterio dell’elenco di blocco del reindirizzamento del contenuto del browser e disabilitare il criterio dei siti di autenticazione.
- Nel caso in cui non siano stati configurati in precedenza siti di autenticazione/intermediari, identificare gli URL intermedi (dalle interazioni di richiesta/risposta negli strumenti per sviluppatori del browser, nella scheda Rete, durante l’esecuzione del flusso di autenticazione senza l’estensione BCR installata) e configurarli nell’elenco di blocco.
Metodo 2: Configurare il Single Sign-On BCR con JSON
Creazione di bcrconfig.json
Il bcrconfig.json può contenere diverse configurazioni di app web. L’estensione BCR tenterà di far corrispondere l’URL richiesto a uno dei allowList specificati da una delle app nell’array di app e applicherà dinamicamente le regole correlate per decidere come gestire il reindirizzamento della pagina e l’elaborazione del Single Sign-On. Le seguenti chiavi possono essere utilizzate per controllare il modo in cui un’app web viene trattata dall’estensione BCR (si noti che i valori booleani devono essere in minuscolo come da specifiche JSON - solo true o false):
- appName [string value, mandatory]: Viene utilizzato principalmente internamente dall’estensione e per scopi di registrazione.
-
allowList [string array, mandatory]: Un’app deve contenere almeno un URL in
allowList, che è l’URL che si intende reindirizzare in modo che il client esegua il rendering della pagina, non il VDA. È possibile definire più URL e sono accettati i caratteri jolly. Le regole dei caratteri jolly sono esattamente le stesse della configurazione ACL del reindirizzamento del contenuto del browser. Ad esempio, per configurare il reindirizzamento di tutte le app Google, utilizzare il seguente array:[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
- denyList [string value, optional]: Definisce gli URL a cui l’applicazione web reindirizza l’utente quando è richiesta l’autenticazione. Questa configurazione è principalmente essenziale per l’autenticazione basata su reindirizzamento, ma può anche essere utilizzata per impedire reindirizzamenti specifici in alcuni flussi di autenticazione basati su moduli. Gli URL elencati in questa chiave non verranno reindirizzati in modo che si verifichi l’autenticazione lato server. È possibile utilizzarla anche quando la condivisione del profilo non è necessaria per limitare specifici sotto-URL di un dominio a non essere reindirizzati al client.
- profileSharing [boolean value, mandatory]: Questo è il valore chiave che deve essere impostato per garantire che i cookie di autenticazione Single Sign-On e altri cookie che memorizzano le preferenze dell’utente vengano condivisi, garantendo un comportamento coerente tra le pagine renderizzate lato server e lato client.
- cookies [string array, optional]: Definisce uno o più cookie di autenticazione necessari affinché l’applicazione web si carichi senza richiedere l’intervento dell’utente. L’estensione impedirà quindi il reindirizzamento lato client finché tutti i cookie elencati qui non saranno rilevati come impostati per l’URL dell’app web specificato. Questa impostazione è utilizzata principalmente per l’autenticazione basata su moduli in-page, ma può anche essere utilizzata per l’autenticazione basata su reindirizzamento, oltre a specificare denyList in determinati scenari.
-
deleteClientCache[boolean value, optional]: Se viene utilizzato il meccanismo di configurazione
bcrconfig.json, il client BCR elimina la cache del browser per impostazione predefinita per una maggiore sicurezza. Questo processo si verifica quando l’utente chiude tutte le schede reindirizzate o avvia una pagina reindirizzata per la prima volta in una sessione. Impostare il valore di questa chiave su false per impedire questo comportamento. Se il dispositivo client è attendibile, l’impostazione di questa chiave su false può migliorare l’esperienza utente. Se il dispositivo client non è attendibile, non impostare questa chiave (o) impostarla su true può migliorare la postura di sicurezza. - schemaVersion [string value, mandatory]: Viene utilizzato principalmente internamente dall’estensione e per scopi di registrazione. Al momento della stesura di questo documento, il suo valore dovrebbe essere impostato su 2511.
Configurazione di esempio
{
"apps": [
{
"appName": "myWebApp1",
"allowList": [
"https://myWebApp1.com/*"
],
"denyList": [],
"requires": {
"profileSharing": false,
"cookies": []
}
},
{
"appName": "myWebApp2",
"allowList": [
"https://myWebApp2.com/*"
],
"denyList": [
"https://myWebApp2.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": []
}
},
{
"appName": "myWebApp3",
"allowList": [
"https://*.myWebApp3.com/"
],
"denyList": [
"https://myWebApp3.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": [
"requiredAuthCookie1",
"requiredAuthCookie2"
]
}
}
],
"preferences": {
"deleteClientCache": true
},
"schemaVersion": "2511"
}
<!--NeedCopy-->
Ecco un file bcrconfig.json di esempio. I suoi elementi sono spiegati in dettaglio di seguito:
La struttura JSON sopra contiene 3 app con configurazioni diverse:
Scenario myWebApp1, nessun SSO:
- Il valore dell’array di stringhe della chiave
allowListspecifica che tutti i percorsi all’interno di https://myWebApp1.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiavedenyList, se presenti. - Il valore dell’array di stringhe della chiave
denyListè vuoto, quindi nessun sito di autenticazione verrà impedito dal reindirizzamento. Pertanto, l’autenticazione non sarà mantenuta strettamente sul lato server. - Il valore booleano della chiave
profileSharingè impostato su false, quindi nessun cookie relativo alle vociallowListverrà condiviso con il client. - L’array di stringhe della chiave dei cookie è vuoto, ma sarebbe stato comunque ignorato poiché la chiave di condivisione
profileSharingè impostata su false.
myWebApp2, scenario di autenticazione basata su reindirizzamento:
-
Il valore dell’array di stringhe della chiave
allowListspecifica che tutti i percorsi all’interno di https://myWebApp2.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiavedenyList, se presenti. -
Il valore dell’array di stringhe della chiave
denyListspecifica che i percorsi che iniziano con/authPortal/sotto il dominio myWebApp2.com verranno impediti dal reindirizzamento lato client in modo che l’autenticazione lato server possa essere eseguita. -
Il valore booleano della chiave
profileSharingè impostato su true, quindi i cookie relativi alle voci allowList verranno condivisi con il client e il single sign-on verrà eseguito. -
L’array di stringhe della chiave dei cookie è vuoto, quindi l’estensione non attenderà che un cookie specifico venga impostato dopo l’autenticazione lato server prima che vengano condivisi con il client.
myWebApp3, scenario di autenticazione basata su moduli:
- Il valore dell’array di stringhe della chiave
allowListspecifica che tutti i percorsi all’interno di https://myWebApp3.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiavedenyList, se presenti. - Il valore dell’array di stringhe della chiave
denyListspecifica che i percorsi che iniziano con/authPortal/sotto il dominio myWebApp3.com verranno impediti dal reindirizzamento lato client in modo che l’autenticazione lato server possa essere eseguita. - Il valore booleano della chiave
profileSharingè impostato su true, quindi i cookie relativi alle vociallowListverranno condivisi con il client. - L’array di stringhe della chiave dei cookie contiene un nome di cookie, quindi l’estensione attenderà che questo cookie venga impostato dopo l’autenticazione lato server. Il cookie per l’URL correlato in
allowListverrà condiviso con il client e si verificherà un reindirizzamento lato client.
Preferenze
- La chiave
deleteClientCacheè impostata su true, quindi il client BCR elimina la cache del browser per impostazione predefinita per una maggiore sicurezza. Questo è il comportamento predefinito anche se la chiave non è impostata.
Configurazione dei criteri BCR
Dopo aver creato bcrconfig.json, seguire i passaggi seguenti per configurare la configurazione ACL di reindirizzamento del contenuto del browser per utilizzare il contenuto del file JSON.
-
Nominare il file con estensione
.bcrconfig.json, ad esempio,myrules.bcrconfig.json -
Ospitare il file JSON su un server web accessibile al VDA e annotare l’URL.
Nota:
Il server deve consentire i download di file; i siti Microsoft IIS consentono i download di file JSON per impostazione predefinita.
-
In Citrix Studio, in Criteri, aggiungere l’URL del passaggio precedente all’impostazione di configurazione ACL di reindirizzamento del contenuto del browser:
Nota:
Altre voci nell’impostazione di configurazione ACL di reindirizzamento del contenuto del browser possono rimanere. L’estensione BCR dà priorità alle impostazioni
bcrconfig.jsonin caso di conflitti. Citrix consiglia di spostare l’intera configurazione su JSON per facilitare la gestione, la configurazione a livello di applicazione e la scalabilità. -
Salvare i criteri e avviare una sessione per testare la configurazione dei criteri.
Nota:
Dopo aver impostato i criteri, è possibile modificare il file
bcrconfig.jsonospitato in qualsiasi momento per la messa a punto. Il file si ricarica e applica le modifiche solo quando il processo principale del browser che esegue l’estensione BCR viene avviato o riavviato.
Nota:
In sostanza, dal punto di vista della policy, è sufficiente abilitare la policy di reindirizzamento dei contenuti del browser (che è abilitata per impostazione predefinita) e configurare la policy di configurazione ACL del reindirizzamento dei contenuti del browser con l’URL che punta al file JSON.
La configurazione JSON attualmente si applica alle seguenti policy e le rende flessibili, ma le restanti policy continuano a eseguire le stesse azioni di prima.
- Configurazione ACL del reindirizzamento dei contenuti del browser: Gli URL nell’ACL possono ora essere configurati tramite JSON tramite la chiave
allowList.- Configurazione della lista di blocco del reindirizzamento dei contenuti del browser: La lista di blocco può ora essere configurata tramite JSON tramite la chiave
denyList.- Siti di autenticazione del reindirizzamento dei contenuti del browser: Anche i siti di autenticazione possono essere configurati tramite JSON tramite la chiave
denyList.