Ogni accesso separato è un’altra password da reimpostare e un altro account da chiudere quando qualcuno se ne va. Il single sign-on (SSO) SAML collega il tuo learning management system al tuo identity provider, così le persone accedono alla formazione con il proprio account di lavoro e l’accesso segue la tua directory. Ecco come funziona SAML, come procede la configurazione con Microsoft Entra ID, Okta o Google Workspace e cosa verificare prima del go-live.
Come funziona il single sign-on SAML
SAML (Security Assertion Markup Language) 2.0 è uno standard aperto per trasmettere le informazioni di accesso tra due sistemi che si fidano l’uno dell’altro. L’LMS non vede mai la password della persona: la indirizza al tuo identity provider, che verifica chi è, con l’eventuale autenticazione a più fattori che richiedi, e la restituisce con una dichiarazione firmata.
| Termine | Significato |
|---|---|
| Identity provider (IdP) | Il sistema che autentica le tue persone, come Entra ID, Okta o Google Workspace. |
| Service provider (SP) | L’applicazione a cui le persone accedono: il tuo LMS. |
| Asserzione | La dichiarazione XML firmata dall’IdP: chi è la persona, quando ha effettuato l’accesso e attributi come email e nome. |
| Entity ID | Un nome univoco per ciascuna delle due parti, spesso con la forma di un URL ma solo un identificativo. Deve corrispondere esattamente. |
| ACS URL | L’Assertion Consumer Service URL: l’indirizzo dell’LMS che riceve la risposta dell’IdP. |
| Certificato di firma | L’IdP firma con la propria chiave privata; l’LMS verifica con il certificato pubblico dell’IdP e rifiuta le asserzioni contraffatte o alterate. |
| Metadati | Un file XML che riunisce un entity ID, gli endpoint e i certificati, pronto da importare. |
Le asserzioni hanno vita breve e indicano il proprio destinatario (l’entity ID dell’SP). L’SP rifiuta tutto ciò che è scaduto o destinato a un’altra applicazione.
Perché l’SSO vale la pena per un LMS
- Nessuna password in più. Le persone usano il proprio account di tutti i giorni e la tua MFA e le tue policy di accesso coprono anche la formazione.
- Chi entra in azienda ottiene l’accesso in fretta. Assegna l’applicazione LMS a un gruppo e i nuovi collaboratori che ne fanno parte possono accedere già dal primo giorno.
- Chi se ne va perde l’accesso alla fonte. Disattiva una persona nella tua directory e non potrà avviare una nuova sessione nell’LMS. SAML controlla l’accesso, non l’account, quindi archivia l’account LMS anche nell’ambito dell’offboarding.
Creazione degli account just-in-time
Con il provisioning just-in-time (JIT), l’LMS crea un account la prima volta che qualcuno accede, a partire dagli attributi dell’asserzione, quindi non c’è alcun elenco di utenti da importare. Mettici dei paletti:
- Limitalo ai tuoi domini email, così un’applicazione configurata male o un account ospite non crea utenti indesiderati.
- Assegna ai nuovi account il ruolo più basso e concedi i diritti di amministratore in modo deliberato.
- Riconosci le persone da un identificatore stabile, dove il tuo IdP può inviarne uno, perché gli indirizzi email cambiano.
Accesso avviato dall’SP e accesso avviato dall’IdP
- Avviato dall’SP: la persona apre l’LMS, che invia una richiesta di autenticazione all’IdP, e l’IdP invia la propria risposta all’ACS URL. Funziona dai preferiti e dai link nelle email ed è generalmente considerato il flusso più sicuro, perché la risposta corrisponde a una richiesta fatta dall’LMS.
- Avviato dall’IdP: la persona clicca il riquadro dell’applicazione in Microsoft My Apps, nella dashboard di Okta o nel menu delle app di Google, e l’IdP invia all’ACS URL una risposta non richiesta.
Puoi offrire entrambi; testali tutti e due.
Configurare l’SSO SAML, passo dopo passo
La sequenza è più o meno la stessa ovunque:
- Pianifica l’ambito: chi usa l’SSO, quali gruppi ricevono l’applicazione, quali domini email sono consentiti e quale attributo identifica ciascuna persona.
- Crea la connessione nell’LMS e annota il suo entity ID e il suo ACS URL.
- Crea un’applicazione SAML nel tuo IdP con quei valori, scegli il formato NameID e aggiungi gli attributi email, nome e cognome.
- Assegna utenti o gruppi; le persone non assegnate di solito vengono respinte.
- Fornisci all’LMS i dati dell’IdP: un URL dei metadati, un file di metadati oppure l’entity ID, l’URL di accesso e il certificato di firma dell’IdP.
- Mappa gli attributi sui nomi che il tuo IdP invia effettivamente.
- Testa, poi attiva, e spiega alle persone che cosa cambia.
Note sui provider
La documentazione del tuo provider contiene le schermate esatte. Vale la pena sapere che:
- Microsoft Entra ID: usa un’applicazione aziendale non presente nella galleria, non una registrazione dell’app, che non offre SAML. I nomi dei claim sono URI lunghi, quindi copiali esattamente. L’object ID è un buon identificatore stabile. Per chi non ha una casella di posta il claim email può essere vuoto; il user principal name può sostituirlo se è un indirizzo reale.
- Okta: crea un’integrazione di app SAML 2.0. Sei tu a dare un nome alle dichiarazioni di attributo, quindi devono corrispondere esattamente alla mappatura dell’LMS, maiuscole comprese. Il suo ID utente interno è un identificatore stabile.
- Google Workspace: aggiungi un’app SAML personalizzata e scarica il suo file di metadati. L’app parte disattivata, quindi attivala per le unità organizzative o i gruppi giusti. Una configurazione tipica identifica le persone dall’email principale, quindi tieni conto di indirizzi rinominati e riutilizzati.
Checklist di test
Prima del go-live, verifica questi punti in una finestra privata del browser:
- Un utente esistente accede partendo dall’LMS e di nuovo dal riquadro dell’app.
- Un nuovo utente sul tuo dominio ottiene un account con il ruolo corretto.
- Chi non è assegnato all’applicazione viene respinto.
- Chi è fuori dai tuoi domini consentiti viene respinto.
- Email, nome e cognome arrivano correttamente.
- Un amministratore riesce ancora ad accedere tramite il percorso di recupero.
Insidie comuni
Sfasamento degli orologi
Se gli orologi dell’IdP e dell’LMS differiscono più di quanto l’LMS tolleri, asserzioni valide vengono rifiutate perché non ancora valide o già scadute. Riguarda soprattutto i server di identità gestiti in proprio, quindi mantieni i loro orologi sincronizzati.
Rinnovo del certificato
I certificati di firma dell’IdP scadono e, se l’LMS non si fida di quello sostitutivo, tutti gli accessi falliscono in una volta sola. Segna in calendario la data di scadenza. Se il tuo LMS può fidarsi di due certificati, aggiungi prima il nuovo lì, poi attivalo nell’IdP; altrimenti passa al nuovo su entrambi i lati insieme, in un momento tranquillo. Testa subito dopo.
Mappatura degli attributi
I nomi degli attributi di solito vengono confrontati in modo esatto: un LMS che si aspetta email non accetterà Email. Controlla anche l’identificatore. Un NameID transitorio cambia a ogni sessione e un indirizzo email può cambiare; un NameID persistente o un attributo ID immutabile è stabile. Se le persone vengono riconosciute dall’email, archivia l’account di chi se ne va prima che il suo indirizzo venga riassegnato.
Domini email non corrispondenti
Le directory spesso includono persone il cui nome di accesso non è il loro indirizzo email, collaboratori esterni su altri domini e personale di aziende acquisite ancora sui vecchi domini. Se l’LMS limita gli account a certi domini, queste persone vengono respinte. Elenca ogni dominio prima del go-live.
Come lo fa Acadenix
L’SSO SAML è incluso nel piano Gold, con guide passo passo per Entra ID, Okta e Google Workspace.
- Testa, poi attiva. Salvi i dati del tuo IdP come bozza, esegui Test configuration (test della configurazione) accedendo dal tuo provider e solo dopo attivi. Un claim email mancante viene segnalato insieme ai nomi dei claim che il tuo provider ha effettivamente inviato.
- Modifiche preparate in anticipo. Un nuovo certificato o tenant viene inserito come aggiornamento della configurazione, e la configurazione attuale continua a funzionare finché non lo attivi.
- JIT entro i tuoi domini. Chi non ha un account ottiene un account discente al primo accesso, solo se la sua email è tra i domini di registrazione della tua organizzazione, e puoi disattivare questa opzione. Quando qualcuno che ha già un account Acadenix accede per la prima volta tramite il tuo IdP, Acadenix gli invia via email un codice monouso per confermare il collegamento. Succede una sola volta per persona.
- Entrambe le vie d’accesso. Le persone partono dalla tua pagina di accesso, che può indirizzarle direttamente al tuo IdP o mostrare un pulsante, oppure dal riquadro in My Apps, Okta o Google.
- Una connessione, un’organizzazione. Una connessione SAML non si trasmette alle organizzazioni sotto quella che ne è titolare, cosa che conta per i gruppi con molte sedi.
- Un percorso di recupero. Se il tuo IdP non è disponibile, gli amministratori possono comunque accedere con un codice monouso inviato via email, e questa opzione non può essere disattivata.
Oltre a SAML, le persone possono accedere con un codice inviato via email o con un account Google, Microsoft o LinkedIn. Maggiori informazioni nella nostra pagina sulla sicurezza.
Punti chiave
- Scambia entity ID, ACS URL e metadati, poi mappa un identificatore stabile e un’email verificata.
- Limita gli account just-in-time ai tuoi domini e al ruolo più basso.
- Testa entrambi i flussi di accesso, i rifiuti e il percorso di recupero prima del go-live.
- Segna in calendario la scadenza dei certificati e archivia gli account LMS di chi se ne va.
Vuoi collegare Acadenix al tuo identity provider? Confronta i piani nella nostra pagina dei prezzi oppure parlaci della tua configurazione.
