Fiecare autentificare separată înseamnă o altă parolă de resetat și un alt cont de închis atunci când cineva pleacă. Autentificarea unică SAML (single sign-on, SSO) conectează sistemul dumneavoastră de gestionare a învățării la furnizorul de identitate, astfel încât oamenii se conectează la instruire cu contul de serviciu, iar accesul urmează directorul dumneavoastră. Iată cum funcționează SAML, cum decurge configurarea cu Microsoft Entra ID, Okta sau Google Workspace și ce trebuie verificat înainte de lansare.
Cum funcționează autentificarea unică SAML
SAML (Security Assertion Markup Language) 2.0 este un standard deschis pentru transmiterea informațiilor de conectare între două sisteme care au încredere unul în celălalt. LMS-ul nu vede niciodată parola persoanei: o trimite la furnizorul dumneavoastră de identitate, care verifică cine este, cu orice autentificare multifactor cerută de dumneavoastră, și o returnează cu o declarație semnată.
| Termen | Ce înseamnă |
|---|---|
| Furnizor de identitate (IdP) | Sistemul care autentifică oamenii dumneavoastră, precum Entra ID, Okta sau Google Workspace. |
| Furnizor de servicii (SP) | Aplicația în care se conectează oamenii: LMS-ul dumneavoastră. |
| Aserțiune (assertion) | Declarația XML semnată de IdP: cine este persoana, când s-a conectat și atribute precum e-mailul și numele. |
| Entity ID | Un nume unic pentru fiecare parte, adesea în forma unui URL, dar doar un identificator. Trebuie să se potrivească exact. |
| URL ACS | Assertion Consumer Service URL: adresa LMS-ului care primește răspunsul IdP-ului. |
| Certificat de semnare | IdP-ul semnează cu cheia sa privată; LMS-ul verifică cu certificatul public al IdP-ului și respinge aserțiunile falsificate sau alterate. |
| Metadate | Un fișier XML care grupează un entity ID, punctele de acces și certificatele, gata de importat. |
Aserțiunile sunt de scurtă durată și indică destinatarul (entity ID-ul SP-ului). SP-ul respinge orice este expirat sau destinat altei aplicații.
De ce merită SSO pentru un LMS
- Fără parole în plus. Oamenii își folosesc contul de zi cu zi, iar MFA și politicile dumneavoastră de acces acoperă și instruirea.
- Cei nou-veniți obțin rapid acces. Atribuiți aplicația LMS unui grup, iar angajații noi din acesta se pot conecta din prima zi.
- Cei care pleacă pierd accesul de la sursă. Dezactivați o persoană în director și nu mai poate porni o sesiune nouă în LMS. SAML controlează conectarea, nu contul, așa că arhivați contul din LMS și în cadrul procedurii de plecare din companie.
Crearea conturilor just-in-time
Cu aprovizionarea just-in-time (JIT), LMS-ul creează un cont la prima conectare a unei persoane, pe baza atributelor din aserțiune, deci nu există o listă de utilizatori de importat. Puneți-i limite de siguranță:
- Limitați-o la propriile domenii de e-mail, ca o aplicație configurată greșit sau un cont de oaspete să nu creeze utilizatori rătăciți.
- Dați conturilor noi cel mai scăzut rol, iar drepturile de administrator acordați-le deliberat.
- Potriviți persoanele după un identificator stabil, acolo unde IdP-ul dumneavoastră poate trimite unul, pentru că adresele de e-mail se schimbă.
Conectare inițiată de SP vs conectare inițiată de IdP
- Inițiată de SP: persoana deschide LMS-ul, care trimite o cerere de autentificare către IdP, iar IdP-ul trimite răspunsul (prin POST) la URL-ul ACS. Funcționează din marcaje și din linkuri din e-mail și este considerată în general fluxul mai sigur, deoarece răspunsul corespunde unei cereri făcute de LMS.
- Inițiată de IdP: persoana dă clic pe pictograma aplicației în Microsoft My Apps, în tabloul de bord Okta sau în meniul de aplicații Google, iar IdP-ul trimite către URL-ul ACS un răspuns nesolicitat.
Le puteți oferi pe amândouă; testați-le pe fiecare.
Configurarea SSO SAML, pas cu pas
Succesiunea este în mare aceeași peste tot:
- Planificați domeniul de aplicare: cine folosește SSO, ce grupuri primesc aplicația, ce domenii de e-mail sunt permise și ce atribut identifică fiecare persoană.
- Creați conexiunea în LMS și notați-i entity ID-ul și URL-ul ACS.
- Creați o aplicație SAML la IdP cu aceste valori, alegeți formatul NameID și adăugați atribute pentru e-mail, prenume și nume de familie.
- Atribuiți utilizatori sau grupuri; persoanele neatribuite sunt de obicei refuzate.
- Dați LMS-ului detaliile IdP-ului: un URL de metadate, un fișier de metadate sau entity ID-ul IdP-ului, URL-ul de conectare și certificatul de semnare.
- Mapați atributele la numele pe care IdP-ul dumneavoastră le trimite efectiv.
- Testați, apoi activați-l și anunțați oamenii ce se schimbă.
Note despre furnizori
Documentația furnizorului dumneavoastră conține ecranele exacte. Merită știut:
- Microsoft Entra ID: folosiți o aplicație enterprise din afara galeriei (non-gallery), nu o înregistrare de aplicație (app registration), care nu oferă SAML. Numele claim-urilor sunt URI-uri lungi, așa că copiați-le exact. ID-ul obiectului (object ID) este un bun identificator stabil. Pentru persoanele fără cutie poștală, claim-ul de e-mail poate fi gol; numele principal de utilizator (user principal name) îl poate înlocui dacă este o adresă reală.
- Okta: creați o integrare de aplicație SAML 2.0. Declarațiile de atribute le denumiți dumneavoastră, deci trebuie să se potrivească exact cu maparea din LMS, inclusiv majusculele. ID-ul intern de utilizator este un identificator stabil.
- Google Workspace: adăugați o aplicație SAML personalizată și descărcați fișierul ei de metadate. Aplicația pornește dezactivată, așa că activați-o pentru unitățile organizaționale sau grupurile potrivite. O configurație tipică identifică persoanele după adresa de e-mail principală, așa că planificați pentru adresele redenumite și refolosite.
Listă de verificare pentru testare
Înainte de lansare, verificați următoarele într-o fereastră privată de browser:
- Un utilizator existent se conectează pornind de la LMS și, din nou, de la pictograma aplicației.
- Un utilizator nou de pe domeniul dumneavoastră primește un cont cu rolul potrivit.
- O persoană neatribuită aplicației este refuzată.
- O persoană din afara domeniilor dumneavoastră permise este refuzată.
- E-mailul, prenumele și numele de familie ajung corect.
- Un administrator poate în continuare să intre prin calea de recuperare.
Capcane frecvente
Decalajul de ceas (clock skew)
Dacă ceasurile IdP-ului și ale LMS-ului diferă cu mai mult decât tolerează LMS-ul, aserțiunile corecte sunt respinse ca „încă nevalabile” sau „deja expirate”. Afectează mai ales serverele de identitate găzduite propriu, așa că mențineți-le ceasurile sincronizate.
Rotirea certificatului
Certificatele de semnare ale IdP-ului expiră, iar dacă LMS-ul nu are încredere în cel înlocuitor, fiecare conectare eșuează deodată. Notați în calendar data expirării. Dacă LMS-ul poate avea încredere în două certificate, adăugați-l mai întâi pe cel nou acolo, apoi activați-l la IdP; altfel, schimbați ambele părți împreună, într-un moment liniștit. Testați imediat.
Maparea atributelor
Numele atributelor sunt de obicei potrivite exact: un LMS care așteaptă email nu va accepta Email. Verificați și identificatorul. Un NameID tranzitoriu se schimbă la fiecare sesiune, iar o adresă de e-mail se poate schimba; un NameID persistent sau un atribut de ID imuabil este stabil. Dacă persoanele sunt potrivite după e-mail, arhivați contul unei persoane care pleacă înainte ca adresa ei să fie realocată.
Nepotrivirea domeniului de e-mail
Directoarele includ adesea persoane al căror nume de conectare nu este adresa lor de e-mail, colaboratori externi pe alte domenii și angajați ai unor afaceri achiziționate, încă rămași pe domeniile vechi. Dacă LMS-ul limitează conturile la anumite domenii, acestea sunt refuzate. Enumerați toate domeniile înainte de lansare.
Cum face Acadenix
SSO SAML este disponibil în planul Gold, cu ghiduri pas cu pas pentru Entra ID, Okta și Google Workspace.
- Testați, apoi activați. Salvați detaliile IdP-ului dumneavoastră ca ciornă, rulați Test configuration (testarea configurației) conectându-vă la furnizorul dumneavoastră și abia apoi activați. Un claim de e-mail lipsă este raportat împreună cu numele claim-urilor pe care furnizorul dumneavoastră le-a trimis de fapt.
- Modificări în etape. Un certificat sau un tenant nou se introduce ca actualizare a configurației, iar configurația curentă continuă să funcționeze până când o activați.
- JIT în limita domeniilor dumneavoastră. O persoană fără cont primește un cont de cursant la prima conectare, doar dacă e-mailul ei se află pe domeniile de înregistrare ale organizației dumneavoastră, iar acest lucru se poate dezactiva. Când o persoană care are deja un cont Acadenix se conectează prima dată prin IdP-ul dumneavoastră, Acadenix îi trimite prin e-mail un cod unic pentru a confirma legătura. Acest lucru se întâmplă o singură dată pentru fiecare persoană.
- Ambele căi de intrare. Oamenii pornesc de la pagina dumneavoastră de conectare, care îi poate duce direct la IdP sau poate afișa un buton, ori de la pictograma din My Apps, Okta sau Google.
- O conexiune, o organizație. O conexiune SAML nu se transmite organizațiilor aflate sub proprietarul ei, ceea ce contează pentru grupurile cu multe locații.
- O cale de recuperare. Dacă IdP-ul dumneavoastră este indisponibil, administratorii se pot conecta în continuare cu un cod unic trimis prin e-mail, iar această cale nu poate fi dezactivată.
Pe lângă SAML, oamenii se pot conecta cu un cod trimis prin e-mail sau cu un cont Google, Microsoft ori LinkedIn. Mai multe pe pagina noastră de securitate.
Concluzii principale
- Schimbați între sisteme entity ID-urile, URL-ul ACS și metadatele, apoi mapați un identificator stabil și un e-mail verificat.
- Limitați conturile just-in-time la propriile domenii și la cel mai scăzut rol.
- Testați ambele fluxuri de conectare, refuzurile și calea de recuperare înainte de lansare.
- Notați în calendar expirarea certificatelor și arhivați conturile LMS ale celor care pleacă.
Vreți să conectați Acadenix la furnizorul dumneavoastră de identitate? Comparați planurile pe pagina noastră de prețuri sau discutați cu noi despre configurația dumneavoastră.
