Supporto per il Single Sign-On

Introduzione

Browser Content Redirection offre ora un’esperienza utente semplificata con il supporto del single sign-on, consentendo l’autenticazione lato VDA e la condivisione dei cookie.

Questo miglioramento elimina i login 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 login.
• 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 (quando già autenticati sul VDA), poiché l’SSO viene preservato senza interruzioni dal browser VDA.
• L’autenticazione avviene dal VDA, il che migliora la postura di sicurezza limitando i requisiti e l’esposizione della rete lato client, fornendo un’esperienza significativamente migliorata e ininterrotta.

Requisiti minimi

• Citrix Virtual Apps and Desktops, versione 2511
• Citrix Workspace App per Windows 2511
• Citrix Workspace App per Linux 2511 (Anteprima)
• Estensione di reindirizzamento del browser (Chrome o Edge) 25.11 o successiva

Sequenze di autenticazione supportate

Attualmente sono supportati due tipi di sequenze di autenticazione 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 con successo su quella pagina, il browser viene reindirizzato all’URL originale dell’applicazione, ora inclusi i cookie di autenticazione richiesti.

Autenticazione basata su moduli nella pagina [Preview]

Questo metodo mantiene l’utente sull’URL dell’applicazione previsto, presentando 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 fino a quando 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 i criteri BCR esistenti in Web Studio e li impiega per ottenere il supporto del Single sign-on.

Prima dell’introduzione del supporto per il Single sign-on, il criterio dei siti di autenticazione per il reindirizzamento del contenuto del browser veniva utilizzato 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 nel criterio dei siti di autenticazione devono ora essere configurati nel criterio dell’elenco 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 nel criterio ACL di BCR. La configurazione JSON offre ulteriore flessibilità.

1. 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.
2. Quando si tratta di autenticazione basata su moduli in-page, il Metodo 1 non offre un modo per impostare cookie di autenticazione specifici in quanto non esistono criteri 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 raccomanda di provare la configurazione basata su JSON.

Passaggio 1: Determinazione del meccanismo di autenticazione

Per determinare quale Metodo utilizzare per la tua configurazione, il primo passo è stabilire quale tipo di meccanismo di autenticazione sta utilizzando la tua applicazione. Per determinare con precisione il metodo di autenticazione dell’applicazione web, l’approccio migliore è contattare l’amministratore dell’applicazione web.

Se ciò 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 nel criterio dell’elenco 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 garantire di avere la configurazione corretta.

1. Apri Chrome, quindi premi CTRL+MAIUSC+I per aprire gli strumenti per sviluppatori.
2. Fare clic sulla scheda Network.
3. Spuntare l’impostazione Preserve log.
4. Fare clic sul filtro Doc per semplificare i log di rete.
5. Fare clic con il pulsante destro del mouse accanto a Name e aggiungere la colonna URL.
6. Accedere a github.com mentre gli strumenti per sviluppatori sono ancora aperti.
7. Accedere a github.com
8. Annotare tutti i passaggi intermedi tra la pagina iniziale di github.com e la sua destinazione dopo che è avvenuto l’accesso.
9. Analizzare le intestazioni di richiesta/risposta per determinare il tipo di autenticazione come specificato sopra.

Passaggio 2: Scegliere un metodo di configurazione

1. Se si utilizza 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.

2. Se si utilizza l’autenticazione basata su moduli nella pagina (o) si utilizzano 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

1. Abilitare la funzionalità nel VDA creando il seguente valore di registro in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1
2. Configurare la policy di configurazione ACL di reindirizzamento del contenuto del browser con i siti web da reindirizzare. Nessuna modifica nella configurazione su questo fronte.
3. Nel caso abbiate già URL configurati nella policy dei siti di autenticazione, copiateli nella policy dell’elenco di blocco del reindirizzamento del contenuto del browser e disabilitate la policy dei siti di autenticazione.
4. Nel caso in cui non abbiate configurato in precedenza siti di autenticazione/intermediari, identificate gli URL intermediari (dalle interazioni richiesta/risposta negli strumenti per sviluppatori del browser, nella scheda Rete, durante l’esecuzione del flusso di autenticazione senza l’estensione BCR installata) e configurateli 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 applicazioni 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 sue 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’applicazione 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]: Questo 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 debba renderizzare la pagina, non il VDA. È possibile definire più URL e i caratteri jolly sono accettati. Le regole dei caratteri jolly sono esattamente le stesse della configurazione ACL di reindirizzamento del contenuto del browser. Ad esempio, per configurare tutte le app Google da reindirizzare, 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 prevenire reindirizzamenti specifici in alcuni flussi di autenticazione basati su moduli. Gli URL elencati in questa chiave non verranno reindirizzati in modo che l’autenticazione lato server abbia luogo. È possibile utilizzarla anche quando la condivisione del profilo non è necessaria per limitare che specifici sotto-URL di un dominio vengano reindirizzati al client.
• profileSharing [boolean value, mandatory]: Questo è il valore della 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, assicurando 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’applicazione web specificata. Questa impostazione viene 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 avviene 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]: Questo viene utilizzato principalmente internamente dall’estensione e per scopi di registrazione. Al momento della stesura, il suo valore dovrebbe essere impostato su 2511.

Esempio di configurazione

{
  "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 allowList specifica che tutti i percorsi all’interno di https://myWebApp1.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiave denyList, 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 voci allowList verrà 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 allowList specifica che tutti i percorsi all’interno di https://myWebApp2.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiave denyList, se presenti.

• Il valore dell’array di stringhe della chiave denyList specifica che i percorsi che iniziano con /authPortal/ nel 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 allowList specifica che tutti i percorsi all’interno di https://myWebApp3.com devono essere reindirizzati al client, ad eccezione dei valori elencati nella chiave denyList, se presenti.
• Il valore dell’array di stringhe della chiave denyList specifica che i percorsi che iniziano con /authPortal/ nel 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.
• 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 allowList verrà 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.

• Denominare 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 il download dei file; i siti Microsoft IIS consentono il 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.json in 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.json ospitato 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 blocklist del reindirizzamento dei contenuti del browser: La blocklist 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.