Ugrás a tartalomhoz
Összes cikk

Biztonság

SAML egyszeri bejelentkezés beállítása az LMS-hez Entra ID-val, Oktával vagy Google Workspace-szel

Gyakorlati útmutató az LMS SSO-hoz SAML-lel: alapfogalmak, beállítás Entra ID-val, Oktával és Google Workspace-szel, tesztlista és a leggyakoribb buktatók.

Acadenix csapata · · 7 perc olvasás


Minden külön bejelentkezés egy újabb jelszó, amelyet vissza kell állítani, és egy újabb fiók, amelyet le kell zárni, amikor valaki távozik. A SAML egyszeri bejelentkezés (SSO) összeköti a tanulásmenedzsment-rendszert az identitásszolgáltatóval, így a munkatársak a munkahelyi fiókjukkal jelentkeznek be a képzésbe, a hozzáférés pedig a címtárat követi. Ebből a cikkből megtudhatja, hogyan működik a SAML, hogyan zajlik a beállítás Microsoft Entra ID-val, Oktával vagy Google Workspace-szel, és mit érdemes ellenőrizni az éles indulás előtt.

Hogyan működik a SAML egyszeri bejelentkezés

A SAML (Security Assertion Markup Language) 2.0 egy nyílt szabvány, amely bejelentkezési információk átadására szolgál két, egymásban megbízó rendszer között. Az LMS soha nem látja a felhasználó jelszavát: átirányítja az identitásszolgáltatóhoz, amely az Ön által előírt többtényezős hitelesítéssel (MFA) együtt ellenőrzi a személy kilétét, majd egy aláírt állítással küldi vissza.

Fogalom Jelentése
Identitásszolgáltató (IdP) Az a rendszer, amely a munkatársait hitelesíti, például az Entra ID, az Okta vagy a Google Workspace.
Szolgáltató (SP) Az alkalmazás, amelybe a felhasználók bejelentkeznek: az Ön LMS-e.
Állítás (assertion) Az IdP aláírt XML-állítása: ki a személy, mikor jelentkezett be, és milyen attribútumai vannak, például e-mail-cím és név.
Entity ID Egyedi név mindkét oldalnak, gyakran URL-alakú, de csak azonosító. Pontosan egyeznie kell.
ACS URL Az Assertion Consumer Service URL: az LMS azon címe, amely fogadja az IdP válaszát.
Aláíró tanúsítvány Az IdP a privát kulcsával ír alá; az LMS az IdP nyilvános tanúsítványával ellenőriz, és elutasítja a hamisított vagy módosított állításokat.
Metaadatok Egy XML-fájl, amely az entity ID-t, a végpontokat és a tanúsítványokat foglalja össze, importálásra készen.

Az állítások rövid életűek, és megnevezik a címzettjüket (az SP entity ID-ját). Az SP elutasít mindent, ami lejárt, vagy egy másik alkalmazásnak szól.

Miért éri meg az SSO egy LMS-nél

  • Nincsenek felesleges jelszavak. A felhasználók a mindennapi fiókjukat használják, és az Ön hozzáférési és MFA-szabályai a képzésre is érvényesek.
  • Az újonnan belépők gyorsan hozzáférnek. Rendelje az LMS-alkalmazást egy csoporthoz, és az abba tartozó új munkatársak már az első napon be tudnak jelentkezni.
  • A távozók a forrásnál veszítik el a hozzáférést. Tiltson le valakit a címtárban, és nem tud új LMS-munkamenetet indítani. A SAML a bejelentkezést szabályozza, nem a fiókot, ezért a kilépési folyamat részeként az LMS-fiókot is archiválja.

Azonnali (just-in-time) fiókkiépítés

Az azonnali (just-in-time, JIT) fiókkiépítés esetén az LMS az első bejelentkezéskor, az állítás attribútumaiból hozza létre a fiókot, így nem kell felhasználói listát importálni. Építsen köré védőkorlátokat:

  • Korlátozza a saját e-mail-domainjeire, hogy egy hibásan beállított alkalmazás vagy vendégfiók ne hozzon létre fölösleges felhasználókat.
  • Az új fiókok a legalacsonyabb szerepkört kapják, az adminisztrátori jogokat pedig tudatosan adja meg.
  • A személyeket stabil azonosító alapján párosítsa, ha az IdP tud ilyet küldeni, mert az e-mail-címek változnak.

SP-kezdeményezett és IdP-kezdeményezett bejelentkezés

  • SP-kezdeményezett: a felhasználó megnyitja az LMS-t, amely hitelesítési kérést küld az IdP-nek, az IdP pedig a válaszát az ACS URL-re postázza. Működik könyvjelzőről és e-mailben kapott hivatkozásról is, és általában biztonságosabb folyamatnak tekintik, mert a válasz egy olyan kérésre érkezik, amelyet az LMS indított.
  • IdP-kezdeményezett: a felhasználó az alkalmazás csempéjére kattint a Microsoft My Apps oldalon, az Okta irányítópultján vagy a Google alkalmazásmenüjében, és az IdP kéretlen választ küld az ACS URL-re.

Mindkettőt kínálhatja; mindkettőt tesztelje.

A SAML SSO beállítása lépésről lépésre

A sorrend mindenhol nagyjából ugyanaz:

  1. Tervezze meg a hatókört: ki használja az SSO-t, mely csoportok kapják meg az alkalmazást, mely e-mail-domainek engedélyezettek, és melyik attribútum azonosítja az egyes személyeket.
  2. Hozza létre a kapcsolatot az LMS-ben, és jegyezze fel az entity ID-t és az ACS URL-t.
  3. Hozzon létre egy SAML-alkalmazást az IdP-nél ezekkel az értékekkel, válassza ki a NameID formátumot, és adja hozzá az e-mail-cím, a keresztnév és a vezetéknév attribútumokat.
  4. Rendeljen hozzá felhasználókat vagy csoportokat; a hozzá nem rendelt személyeket általában elutasítják.
  5. Adja meg az LMS-nek az IdP adatait: egy metaadat-URL-t, egy metaadatfájlt, vagy az IdP entity ID-ját, bejelentkezési URL-jét és aláíró tanúsítványát.
  6. Képezze le az attribútumokat azokra a nevekre, amelyeket az IdP ténylegesen küld.
  7. Tesztelje, majd kapcsolja be, és tájékoztassa a felhasználókat a változásról.

Megjegyzések szolgáltatónként

A pontos képernyőket a szolgáltató dokumentációja mutatja. Érdemes tudni:

  • Microsoft Entra ID: galérián kívüli vállalati alkalmazást (non-gallery enterprise application) használjon, ne alkalmazásregisztrációt, amely nem kínál SAML-t. A claim-nevek hosszú URI-k, ezért pontosan másolja át őket. Az objektumazonosító (object ID) jó stabil azonosító. Postafiók nélküli személyeknél az e-mail claim üres lehet; ilyenkor a felhasználói egyszerű név (user principal name) helyettesítheti, ha valós cím.
  • Okta: hozzon létre egy SAML 2.0 alkalmazásintegrációt. Az attribútum-állításokat (attribute statements) Ön nevezi el, ezért azoknak pontosan egyezniük kell az LMS leképezésével, a kis- és nagybetűket is beleértve. A belső felhasználói azonosítója jó stabil azonosító.
  • Google Workspace: adjon hozzá egy egyéni SAML-alkalmazást, és töltse le a metaadatfájlját. Az alkalmazás kikapcsolt állapotban indul, ezért kapcsolja be a megfelelő szervezeti egységeknek vagy csoportoknak. Egy tipikus beállítás az elsődleges e-mail-cím alapján azonosítja a személyeket, ezért számoljon az átnevezett és újrahasznosított címekkel.

Tesztelési ellenőrzőlista

Az éles indulás előtt ezeket ellenőrizze privát böngészőablakban:

  • Egy meglévő felhasználó bejelentkezik az LMS-ből indulva, majd újra az alkalmazás csempéjéről.
  • A domainjén lévő új felhasználó fiókot kap a megfelelő szerepkörrel.
  • Azt, akit nem rendeltek hozzá az alkalmazáshoz, elutasítják.
  • Az engedélyezett domainjein kívüli személyt elutasítják.
  • Az e-mail-cím, a keresztnév és a vezetéknév helyesen érkezik meg.
  • Egy adminisztrátor a helyreállítási útvonalon még mindig be tud jutni.

Gyakori buktatók

Óraeltérés

Ha az IdP és az LMS órája az LMS által tűrtnél nagyobb mértékben eltér egymástól, a jó állításokat még nem érvényesként vagy már lejártként utasítják el. Ez leginkább a saját üzemeltetésű identitáskiszolgálókat érinti, ezért tartsa szinkronban az óráikat.

Tanúsítványcsere

Az IdP aláíró tanúsítványai lejárnak, és ha az LMS nem bízik meg a helyettesítőben, egyszerre minden bejelentkezés meghiúsul. Jegyezze fel a naptárába a lejárati dátumot. Ha az LMS két tanúsítványban is meg tud bízni, először ott adja hozzá az újat, majd aktiválja az IdP-nél; ellenkező esetben nyugodt időszakban cserélje ki mindkét oldalon egyszerre. Azonnal tesztelje.

Attribútum-leképezés

Az attribútumok neveit általában pontosan egyeztetik: az email nevet váró LMS nem fogadja el az Email nevet. Az azonosítót is ellenőrizze. Az átmeneti (transient) NameID minden munkamenetben változik, az e-mail-cím pedig megváltozhat; a tartós (persistent) NameID vagy egy megváltoztathatatlan azonosító-attribútum stabil. Ha a személyeket e-mail-cím alapján párosítják, archiválja a távozó fiókját, mielőtt a címét újra kiadják.

E-mail-domain eltérés

A címtárakban gyakran vannak olyan személyek, akiknek a bejelentkezési neve nem az e-mail-címük, más domaineken dolgozó külső vállalkozók, illetve felvásárolt cégek munkatársai, akik még a régi domainjeiket használják. Ha az LMS meghatározott domainekre korlátozza a fiókokat, őket elutasítja. Az éles indulás előtt írja össze az összes domaint.

Így működik az Acadenixben

A SAML SSO a Gold-csomagban érhető el, lépésről lépésre szóló útmutatókkal az Entra ID-hoz, az Oktához és a Google Workspace-hez.

  • Először tesztelés, aztán aktiválás. Az IdP adatait vázlatként menti el, a Test configuration (konfiguráció tesztelése) funkcióval bejelentkezik a szolgáltatójánál, és csak azután aktiválja. A hiányzó e-mail claimről szóló jelzés azokat a claim-neveket is megadja, amelyeket a szolgáltatója ténylegesen küldött.
  • Szakaszos módosítások. Az új tanúsítvány vagy bérlő (tenant) konfigurációfrissítésként kerül be, és a jelenlegi konfiguráció addig működik tovább, amíg Ön nem aktiválja az újat.
  • JIT a saját domainjein belül. Aki nem rendelkezik fiókkal, az első bejelentkezéskor tanulói fiókot kap, de csak akkor, ha az e-mail-címe szerepel a szervezet regisztrációs domainjei között, és ezt ki is kapcsolhatja. Amikor valaki, akinek már van Acadenix-fiókja, először jelentkezik be az Ön IdP-jén keresztül, az Acadenix egyszer használatos kódot küld neki e-mailben a kapcsolat megerősítéséhez. Ez személyenként egyszer történik meg.
  • Mindkét irányból be lehet lépni. A felhasználók az Ön bejelentkezési oldaláról indulnak, amely közvetlenül az IdP-hez irányíthatja őket, vagy megjeleníthet egy gombot, illetve a My Apps, az Okta vagy a Google csempéjéről.
  • Egy kapcsolat, egy szervezet. A SAML-kapcsolat nem öröklődik a tulajdonosa alatti szervezetekre, ami a sok telephelyes csoportoknál számít.
  • Helyreállítási útvonal. Ha az IdP leáll, az adminisztrátorok továbbra is be tudnak jelentkezni e-mailben küldött egyszer használatos kóddal, és ez nem kapcsolható ki.

A SAML mellett a felhasználók e-mailben küldött kóddal, illetve Google-, Microsoft- vagy LinkedIn-fiókkal is bejelentkezhetnek. Bővebben a biztonsági oldalunkon.

A legfontosabb tudnivalók

  • Cserélje ki az entity ID-kat, az ACS URL-t és a metaadatokat, majd képezzen le egy stabil azonosítót és egy ellenőrzött e-mail-címet.
  • Az azonnali fiókokat korlátozza a saját domainjeire és a legalacsonyabb szerepkörre.
  • Az éles indulás előtt tesztelje mindkét bejelentkezési folyamatot, az elutasításokat és a helyreállítási útvonalat.
  • Jegyezze fel a tanúsítványok lejáratát, és archiválja a távozók LMS-fiókjait.

Össze szeretné kötni az Acadenixet az identitásszolgáltatójával? Hasonlítsa össze a csomagokat az árak oldalunkon, vagy beszéljen velünk a beállításáról.

Gyakori kérdések

Rendszergazdai hozzáférésre az identitásszolgáltatóhoz és az LMS-hez. Az LMS megadja az entity ID-ját és az ACS URL-jét, az identitásszolgáltató a metaadatait (entity ID, bejelentkezési URL és aláíró tanúsítvány), Önnek pedig meg kell állapodnia arról, mely attribútumok azonosítják az egyes személyeket.
Igen, ha az LMS támogatja az azonnali (just-in-time) fiókkiépítést, amely az első bejelentkezéskor hozza létre a fiókot. Az Acadenixben ezek tanulói fiókok, és csak azoknak jönnek létre, akiknek az e-mail-címe szerepel a szervezet regisztrációs domainjei között.
Akik az SSO-ra támaszkodnak, addig nem tudnak bejelentkezni, amíg vissza nem áll, ezért tartson fenn helyreállítási útvonalat az adminisztrátoroknak. Az Acadenixben az adminisztrátorok mindig be tudnak jelentkezni az e-mailben küldött egyszer használatos kóddal, és ez az útvonal nem kapcsolható ki.
Az SP-kezdeményezett bejelentkezést, amikor a felhasználók az LMS-nél kezdik, általában biztonságosabb folyamatnak tekintik, mert a válasz egy olyan kéréshez kötődik, amelyet az LMS indított. Az alkalmazás csempéjéről indított, IdP-kezdeményezett bejelentkezés kényelmes, és mindkettőt kínálhatja.

Olvasson tovább

Készen áll arra, hogy a képzés adminisztráció nélkül működjön?

Igényeljen próbahozzáférést, töltse fel meglévő SCORM-kurzusait, és tapasztalja meg, milyen az Acadenix a saját tartalmaival.

Bejelentkezés