Introduzione 

Sulla piattaforma, si può configurare il single sign-on (SSO), che permette agli utenti di accedere utilizzando le credenziali di un account esterno come un sistema istituzionale, una rete aziendale o un altro identity provider.

• Quando il SSO è abilitato, gli utenti non devono inserire un username e una password creati specificamente per la piattaforma.
• Al contrario, possono cliccare un pulsante di login (o essere automaticamente reindirizzati) per autenticarsi tramite la pagina dell'identity provider esterno, dopo di che vengono riportati in modo sicuro alla piattaforma.  

Questo articolo illustra dettagli di configurazione e indicazioni per la risoluzione dei problemi applicabili a diverse configurazioni SSO. Le informazioni qui contenute completano quelle fornite nell'articolo specifico per il protocollo o integrazione particolare.

Tipi di configurazioni SSO

La piattaforma formativa supporta più modalità di configurazione del single sign-on, inclusi protocolli standard e integrazioni dirette:

Protocolli standard

• Protocollo Open ID connect: si può configurare l'app Open ID Connect per impostare il single sign-on con l'identity provider scelto, come Okta, Salesforce, Onelogin, Microsoft Entra ID, ecc.
• Protocollo SAML: si può similmente configurare l'app SAML per impostare il single sign-on utilizzando diversi identity provider.  

Attenzione: per ogni protocollo si può configurare un solo identity provider sullo stesso dominio (piattaforma principale o extended enterprise). Ad esempio, se si configura OpenID Connect con Okta come identity provider, non si può configurare un'altra istanza OpenID Connect con un provider diverso sullo stesso dominio. Tuttavia, si può farlo su un dominio extended enterprise separato.  

Integrazioni dirette

La piattaforma supporta anche diverse integrazioni SSO dirette con identity provider, inclusi Auth0, Gmail e Google Apps. 

Single sign-on esterno

È anche possibile forzare gli utenti non autenticati a un URL SSO esterno specificato. Nella scheda SSO dell'app API e SSO, selezionare l'opzione Forza il SSO esterno e inserire l'URL SSO esterno richiesto. Con questa impostazione, quando gli utenti accedono all'URL della piattaforma verranno automaticamente reindirizzati all'URL SSO esterno specificato. 

Attenzione: l'opzione Forza il SSO esterno, quando abilitata, sovrascrive tutti gli altri metodi di accesso: 
- La pagina di login standard non verrà mostrata, quindi gli utenti non potranno accedere con le credenziali della piattaforma, né usare alcun pulsante SSO sulla pagina di login standard. 
- Inoltre, il reindirizzamento all'URL SSO esterno ha la precedenza su qualsiasi reindirizzamento automatico all'identity provider che si configura per altri metodi SSO.  
In pratica, significa che solo l'URL SSO esterno può essere usato per accedere alla piattaforma. 

Configurazione SSO

→ Si vedranno queste impostazioni quando si configura il SSO tramite i protocolli OpenID Connect o SAML, o tramite l'integrazione diretta Auth0.

Le impostazioni di Configurazione SSO permettono di configurare come gli utenti effettueranno l'accesso alla piattaforma tramite single sign-on. Sono disponibili due opzioni: Mostra pagina di login predefinita e Reindirizza automaticamente all'identity provider.

Mostra la pagina di login predefinita:

Con questa opzione, quando gli utenti cliccano su Accedi nell'intestazione della piattaforma, vedranno il normale modulo di Accesso con i campi per inserire le credenziali della piattaforma.

• Se si seleziona anche Mostra il pulsante SSO nella pagina di login, sotto i campi Username e Password, gli utenti vedranno un pulsante per accedere con SSO.  Questo pulsante avrà un logo corrispondente al particolare protocollo SSO o identity provider configurato.
• Quando cliccano questo pulsante SSO, vengono reindirizzati a una pagina per autenticarsi con l'identity provider e, se l'autenticazione ha successo, accedono alla piattaforma.

Suggerimento: nel Menu amministrazione > Configurazione aspetto e branding > Pagina di login si può impostare l'opzione Mostra solo i pulsanti SSO e nascondi modulo di login, in questo caso il modulo di accesso mostrerà solo i pulsanti SSO, ma non i campi username e password.  

Attenzione: se non si sceglie di mostrare il pulsante SSO, gli utenti non potranno iniziare il login SSO dalla pagina principale della piattaforma.

Reindirizza automaticamente all'identity provider: 

Con questa seconda opzione, gli utenti non vedono il modulo di accesso della piattaforma e non devono cliccare alcun pulsante di login SSO. Invece, quando tentano di accedere all'URL della piattaforma, vengono automaticamente reindirizzati alla pagina per autenticarsi con l'identity provider. Poi, se l'autenticazione ha successo, accedono alla piattaforma.

Si noti che con l'opzione di reindirizzamento automatico gli utenti non possono visualizzare la pagina pubblica e non possono scegliere tra opzioni alternative di accesso. Con questo metodo, sono obbligati ad autenticarsi con l'identity provider configurato. 

È buona pratica evitare di abilitare l'opzione Reindirizza automaticamente all'identity provider finché non si ha confermato che il SSO funziona correttamente. Altrimenti, si rischia di rimanere bloccato fuori dalla piattaforma se il reindirizzamento è attivo e il SSO non funziona.

Note sul reindirizzamento automatico:
se alcuni degli utenti non sono gestiti dall'identity provider (IdP), e devono accedere alla piattaforma con credenziali native, non abilitare il Reindirizzo automaticamente all'identity provider, perché questo impedirebbe agli utenti non IdP di effettuare il login. 
Invece, scegliere l'opzione Mostra il pulsante SSO nella pagina di login: 
- Questo consente agli utenti gestiti dall'IdP di accedere tramite SSO, mentre gli utenti esterni all'IdP possono continuare a effettuare il login usando il modulo di login nativo della piattaforma. 
- L'app Extended Enterprise può anche essere utilizzata per configurare comportamenti di accesso diversi per gruppi o pubblici specifici. 

Pagina di destinazione del logout

Con il reindirizzamento automatico, quando un utente esce dalla piattaforma viene inviato a una pagina di destinazione predefinita “Ti sei scollegato correttamente”. Lì può chiudere la pagina oppure usare il pulsante di nuovo login per autenticarsi nuovamente. 

Se si desidera, si può reindirizzare gli utenti che escono a una pagina diversa, inserendo il suo URL nel campo Pagina di destinazione del logout.

Configurazione di logout

→ Si vedranno queste impostazioni quando si configura il SSO tramite i protocolli OpenID Connect o SAML, o tramite l'integrazione diretta Auth0.

L'opzione Configurazione di logout permette di impostare se l'utente debba essere automaticamente disconnesso anche dall'identity provider quando esce dalla piattaforma.  

• In alcune configurazioni SSO, quando questa opzione è selezionata, appare un campo di testo Endpoint di logout. Qui si può definire un URL dove gli utenti atterreranno dopo aver effettuato il logout dalla piattaforma e dal provider di identità. 

Attenzione: per evitare conflitti, se si sta usando l'opzione Reindirizza automaticamente all'identity provider non bisogna abilitare l'opzione Configurazione di logout. 

Attributo username

→ Si vedrà questa impostazione quando si configura il SSO tramite i protocolli OpenID Connect o SAML, o tramite l'integrazione diretta Auth0.

Quando si implementa il single sign-on (SSO) tramite un identity provider, la decisione se un utente che effettua il login via SSO esista già all'interno della piattaforma dipende tipicamente da un campo identificatore univoco ricevuto dall'identity provider. 

Nel campo Attributo username, si può impostare il campo che si vuole usare a questo scopo:

• Quando si fa la selezione, assicurarsi che il campo selezionato sia popolato per tutti i propri utenti nell'identity provider.
• Il campo selezionato deve anche essere unico. Ad esempio, se si seleziona family_name, bisogna essere sicuri che nessuno dei propri utenti abbia lo stesso cognome nell'identity provider.
• Ad esempio, si può usare email come Attributo username, a condizione che tutti i propri utenti abbiano email distinte sul lato provider. 

Il campo dell'identity provider che si seleziona in Attributo username sarà associato (di default*) al campo Username sulla piattaforma. Questo significa che:
- Se i due campi corrispondono, l'utente che si autentica via SSO è considerato già esistente nella piattaforma e accederà a quell'account.
- Se non viene trovato nessun Username corrispondente nella piattaforma, allora l'utente SSO non esiste ancora nella piattaforma, ma può essere creato automaticamente se si configura il Provisioning utenti. 
*solo nella configurazione standard SAML, si può modificare questo default per scegliere un campo diverso.

Provisioning utenti

→ Si vedranno queste impostazioni quando si configura. il SSO tramite i protocolli OpenID Connect o SAML, o tramite l'integrazione diretta Auth0

Il provisioning utenti permette di creare automaticamente un nuovo utente nella piattaforma se l'autenticazione SSO è valida ma quell'utente non esiste ancora nella piattaforma. Permette anche di aggiornare automaticamente i dettagli di un utente nella piattaforma basandosi sulle informazioni corrispondenti nell'identity provider SSO. 

Suggerimento: di default, un utente è considerato già esistente nella piattaforma se il suo Username corrisponde al campo dell'identity provider che si ha impostato come Attributo username. Vedere il capitolo Attributo username. 

Creare il provisioning utenti

Quando si Abilita il provisioning utenti, un utente che effettua il login via SSO e che non esiste ancora nella piattaforma sarà creato subito, con Username della piattaforma = il campo provider impostato in Attributo username.  

Nota sulla collocazione nel ramo predefinito: per il SSO sulla piattaforma principale, gli utenti appena creati saranno collocati nel ramo principale. Per il SSO su un extended enterprise client, gli utenti appena creati saranno collocati nel ramo associato al cliente.

Aggiungere altri campi provisioning 

Oltre allo Username, si potrebbe voler popolare altri dettagli di un utente provisioning usando le informazioni recuperate dall'identity provider. 

Configurare questo nella sezione Aggiungi campi. Questa apparirà leggermente diversa a seconda della configurazione SSO che si sta usando, ma in tutti i casi permette di associare altri campi lato identity provider con i corrispondenti campi della piattaforma. 

Notare che ogni campo della piattaforma e campo dell'identity provider può essere usato una sola volta. Non si possono associare più campi della piattaforma allo stesso campo IdP, né viceversa. 

Suggerimento: se nella piattaforma in Configurazione avanzata > Autoregistrazione si ha selezionato l'opzione Nome e cognome sono obbligatori per la registrazione, assicurarsi di includere questi campi nella sezione Aggiungi campi, affinché gli utenti provisioning possano essere creati.  
Analogamente, se si hanno impostato alcuni campi aggiuntivi utente come obbligatori nella piattaforma, assicurarsi che siano mappati qui in modo che possano essere popolati, altrimenti l'utente non potrà essere creato correttamente. 

Aggiornare i campi provisioning

Selezionare la casella Se l'utente esiste già, aggiorna le sue informazioni per aggiornare automaticamente, all'interno della piattaforma, i valori di qualsiasi campo provisioning che siano stati modificati sul lato identity provider. Se non si seleziona questa opzione, bisogna copiare manualmente eventuali modifiche per mantenere allineati i campi provisioning.  

Bloccare i campi provisioning utente

Selezionare la casella Blocca campi provisioning utente per impedire agli utenti di modificare, in Il mio profilo, qualsiasi campo utente che sia provisioning. Questi campi appariranno grigi e contrassegnati come disabilitati, così che l'utente non possa cambiare il valore ottenuto dall'identity provider. 

→ Notare, tuttavia, che un Superadmin o Power User può comunque modificare i valori di questi campi provisioning bloccati in Gestione utenti con la seguente limitazione: possono essere modificati solo i campi informativi utente, mentre i campi aggiuntivi utente, se bloccati, non possono essere modificati da nessuno. 

Se si ha più di un metodo SSO configurato, si potrebbero incontrare problemi dovuti a interazioni tra campi bloccati. Per dettagli su questo vedere il capitolo Conflitti di provisioning tra più configurazioni SSO

Si prega di notare che tutte le impostazioni di provisioning descritte qui si applicano solo agli utenti che accedono tramite SSO (single sign-on). Ad esempio, i campi provisioning bloccati non saranno disabilitati per gli utenti che accedono usando credenziali della piattaforma. 

Conflitti di provisioning tra più configurazioni SSO

Si raccomanda di evitare di avere più metodi SSO attivi con provisioning sullo stesso dominio, poiché potrebbero verificarsi interferenze o conflitti. Questi problemi possono sorgere anche se alcuni provider SSO non sono completamente configurati.

Si noti che qui ci riferiamo a una situazione in cui più provider SSO sono attivi sulla stessa piattaforma principale o sullo stesso extended enterprise client/dominio. Si può, tuttavia, utilizzare metodi SSO diversi su domini diversi. 

Interazione tra campi bloccati con più provider SSO

Su piattaforme con più di un provider SSO attivo per lo stesso dominio, si possono incontrare comportamenti incoerenti nel blocco dei campi se entrambi i provider hanno abilitato il Provisioning ma con impostazioni diverse per Blocca campi provisioning utenti (uno impostato su ON, l'altro su OFF). 

Ad esempio: 
- I campi possono rimanere bloccati anche per il provider con blocco impostato su OFF
- Viceversa, i campi possono essere sbloccati per il provider con blocco impostato su ON

→ Notare che questo comportamento si verifica solo quando più provider SSO sono attivi sulla stessa piattaforma principale o sullo stesso extended enterprise client/dominio. Tuttavia, le impostazioni di blocco dei campi in un dominio non influenzano altri domini.

SSO con campi provisioning e opzioni di blocco diverse

Un problema correlato che può verificarsi è quando due configurazioni SSO hanno campi aggiuntivi provisioning diversi, in particolare quando un SSO fornisce e blocca un campo obbligatorio che l'altro SSO non fa. Ad esempio: 

• SSO 1: configurato per fornire il campo aggiuntivo utente obbligatorio “myfield”, con l'opzione Blocca campi provisioning utenti selezionata
• SSO 2: NON fornisce “myfield”

Se un utente accede con SSO 2,  il login potrebbe fallire perché “myfield” è obbligatorio ma non può essere compilato perché è bloccato da SSO 1. 

Per risolvere i conflitti di provisioning:

Se si incontra un conflitto di provisioning come quelli descritti sopra, si può risolverlo nei seguenti modi: 

• Se possibile, considerare di avere un solo metodo SSO configurato su un dato dominio (piattaforma principale o extended enterprise client).
• Se si ha bisogno di più metodi SSO, mantenere il provisioning abilitato su uno solo di essi, e disabilitare il provisioning dagli altri SSO  (gli utenti interessati dovrebbero quindi essere aggiunti all'SSO che ha il provisioning abilitato, e aggiornati con un login)
• Se si deve mantenere più SSO con provisioning, assicurarsi di allineare attentamente le configurazioni di provisioning di tutti gli SSO in modo che abbiano gli stessi campi aggiuntivi e opzioni di blocco. In particolare assicurarsi che i campi aggiuntivi utente obbligatori siano con provisioning.
• Se un campo aggiuntivo obbligatorio sta causando il problema, impostarlo nella piattaforma come non obbligatorio.