
SSO Moodle: integrare l’identità aziendale con la piattaforma mantenendo separati login, provisioning utenti, attributi e ruoli applicativi.
SSO Moodle: identity provider, SAML/OIDC, provisioning, mapping attributi, utenti, ruoli, logout, sicurezza e integrazione con portali.
Implementazione Single Sign-On specifica per Moodle.
SSO Moodle: identity provider, SAML/OIDC, provisioning, mapping attributi, utenti, ruoli, logout, sicurezza e integrazione con portali.
L’IdP resta il sistema che autentica la persona.
Colleghiamo Moodle all’identity provider aziendale con un contratto di integrazione chiaro.


Il protocollo viene scelto sul contesto e sui sistemi disponibili.
Scegliamo SAML, OIDC o altro protocollo in base a IdP, vincoli e supporto Moodle.
L’account Moodle deve essere associato a un identificativo stabile.
Definiamo matching utenti su username, email o id esterni per evitare duplicati e lockout.


Nome, email e altri attributi vengono mappati in modo esplicito.
Mappiamo attributi IdP verso campi Moodle con regole esplicite e versionate.
L’utente può essere creato prima o al primo accesso.
Automatizziamo provisioning e aggiornamento profili dove l’IdP è sorgente affidabile.


La migrazione verso SSO deve evitare account duplicati.
Gestiamo utenti già presenti: merge, rename e migrazione account senza perdere storico corsi.
Il login non assegna automaticamente privilegi Moodle.
Separiamo autenticazione federata dall’assegnazione ruoli Moodle: login non implica privilegi.


Attributi esterni possono alimentare assegnazioni solo con regole controllate.
Sincronizziamo cohort e gruppi solo quando regole e ownership sono definite.
La chiusura sessione locale e quella dell’IdP possono avere comportamenti diversi.
Progettiamo logout locale e, dove richiesto, comportamento rispetto al Single Logout.


Moodle e IdP devono avere aspettative compatibili.
Allineiamo durata sessione Moodle e policy IdP per evitare accessi fantasma o friction inutile.
Gli amministratori richiedono una via di emergenza progettata.
Garantiamo un percorso admin di emergenza indipendente dall’IdP in caso di outage.


Chiavi e redirect vengono gestiti come configurazione sensibile.
Governiamo certificati, metadata e secret con scadenze e rotazione pianificate.
Successo, errore e account non riconosciuti vengono testati.
Testiamo login, mapping, nuovi utenti e casi limite prima del cutover.


Login e provisioning devono essere ricostruibili.
Lasciamo audit su accessi, fallimenti e cambi di mapping per indagini successive.
La soluzione deve restare compatibile con il lifecycle Moodle.
Verifichiamo che plugin SSO e mapping restino sicuri dopo upgrade Moodle o IdP.


Lo SSO Moodle funziona quando identità, mapping e ruoli restano separati e verificabili.
Progettiamo IdP, attributi, provisioning e test affinché accesso e permessi non si confondano.
Cosa dicono i clienti che lavorano con Atlas Learning.
Domande frequenti su SSO Moodle.
Quali protocolli SSO supportate su Moodle?
Principalmente SAML e OIDC, in base all’IdP e ai plugin disponibili.
Come evitate utenti duplicati?
Con regole di matching e migrazione account esistenti prima del go-live.
I ruoli Moodle arrivano dall’IdP?
Solo se richiesto; di base autentichiamo e governiamo i ruoli dentro Moodle.
Cosa succede se l’IdP non è disponibile?
Prevediamo admin di fallback e procedure di continuità concordate.
Fate test prima del cutover?
Sì. Login, mapping, provisioning, logout e casi limite vengono validati.
Cosa influenza tempi e costi?
IdP, protocollo, utenti esistenti, mapping, sync gruppi e vincoli di sicurezza.