Varje separat inloggning är ännu ett lösenord att återställa och ännu ett konto att stänga när någon slutar. Enkel inloggning (SSO) med SAML kopplar din utbildningsplattform (LMS) till din identitetsleverantör, så att folk loggar in på utbildningen med sitt jobbkonto och åtkomsten följer din katalog. Så fungerar SAML, så går uppsättningen till med Microsoft Entra ID, Okta eller Google Workspace och det här ska du kontrollera före driftsättning.
Så fungerar enkel inloggning med SAML
SAML (Security Assertion Markup Language) 2.0 är en öppen standard för att skicka inloggningsinformation mellan två system som litar på varandra. LMS:et ser aldrig personens lösenord: det skickar personen till din identitetsleverantör, som kontrollerar vem personen är, med den flerfaktorsautentisering du kräver, och skickar tillbaka personen med ett signerat intyg.
| Begrepp | Vad det betyder |
|---|---|
| Identitetsleverantör (IdP) | Systemet som autentiserar dina medarbetare, till exempel Entra ID, Okta eller Google Workspace. |
| Tjänsteleverantör (SP) | Applikationen som folk loggar in på: ditt LMS. |
| Assertion | Det signerade XML-intyget från IdP:n: vem personen är, när personen loggade in och attribut som e-post och namn. |
| Entity ID | Ett unikt namn för varje sida, ofta utformat som en URL men bara en identifierare. Det måste matcha exakt. |
| ACS URL | Assertion Consumer Service URL: den LMS-adress som tar emot IdP:ns svar. |
| Signeringscertifikat | IdP:n signerar med sin privata nyckel; LMS:et verifierar med IdP:ns publika certifikat och avvisar förfalskade eller ändrade assertions. |
| Metadata | En XML-fil som samlar ett entity ID, slutpunkter och certifikat, redo att importeras. |
Assertions är kortlivade och anger sin mottagare (SP:ns entity ID). SP:n avvisar allt som har gått ut eller är avsett för en annan applikation.
Därför är SSO värt det för ett LMS
- Inga extra lösenord. Folk använder sitt vardagskonto, och din MFA och dina åtkomstpolicyer gäller även utbildningen.
- Nyanställda får snabbt åtkomst. Tilldela LMS-applikationen till en grupp, så kan nya medarbetare i den logga in redan första dagen.
- De som slutar förlorar åtkomsten vid källan. Inaktivera någon i din katalog och personen kan inte starta någon ny LMS-session. SAML styr inloggningen, inte kontot, så arkivera även LMS-kontot som en del av avslutningsrutinen.
Kontoskapande just-in-time
Med just-in-time-provisionering (JIT) skapar LMS:et ett konto första gången någon loggar in, utifrån assertionens attribut, så det finns ingen användarlista att importera. Sätt skyddsräcken runt det:
- Begränsa det till dina egna e-postdomäner, så att en felkonfigurerad applikation eller ett gästkonto inte skapar oönskade användare.
- Ge nya konton den lägsta rollen och ge administratörsbehörighet medvetet.
- Matcha personer på en stabil identifierare där din IdP kan skicka en, eftersom e-postadresser ändras.
SP-initierad respektive IdP-initierad inloggning
- SP-initierad: personen öppnar LMS:et, som skickar en autentiseringsförfrågan till IdP:n, och IdP:n postar sitt svar till ACS URL:en. Det fungerar från bokmärken och länkar i e-post och anses generellt vara det säkrare flödet eftersom svaret besvarar en förfrågan som LMS:et har gjort.
- IdP-initierad: personen klickar på applikationens ruta i Microsoft My Apps, sin Okta-dashboard eller Googles appmeny, och IdP:n skickar ett obegärt svar till ACS URL:en.
Du kan erbjuda båda; testa var och en.
Så sätter du upp SAML SSO, steg för steg
Ordningen är ungefär densamma överallt:
- Planera omfattningen: vem som använder SSO, vilka grupper som får applikationen, vilka e-postdomäner som är tillåtna och vilket attribut som identifierar varje person.
- Skapa anslutningen i LMS:et och notera dess entity ID och ACS URL.
- Skapa en SAML-applikation hos din IdP med de värdena, välj NameID-format och lägg till attribut för e-post, förnamn och efternamn.
- Tilldela användare eller grupper; personer som inte är tilldelade avvisas vanligtvis.
- Ge LMS:et IdP:ns uppgifter: en metadata-URL, en metadatafil eller IdP:ns entity ID, inloggnings-URL och signeringscertifikat.
- Mappa attributen till de namn som din IdP faktiskt skickar.
- Testa och slå sedan på det, och berätta för folk vad som ändras.
Anteckningar per leverantör
Din leverantörs dokumentation visar de exakta vyerna. Bra att veta:
- Microsoft Entra ID: använd en enterprise-applikation utanför galleriet, inte en appregistrering, som inte erbjuder SAML. Claim-namnen är långa URI:er, så kopiera dem exakt. Objekt-ID:t är en bra stabil identifierare. För personer utan postlåda kan e-postclaimet vara tomt; användarens huvudnamn (UPN) kan ersätta det om det är en riktig adress.
- Okta: skapa en SAML 2.0-appintegration. Du namnger attributsatserna själv, så de måste matcha LMS:ets mappning exakt, inklusive gemener och versaler. Oktas interna användar-ID är en stabil identifierare.
- Google Workspace: lägg till en egen SAML-app och ladda ner dess metadatafil. Appen är avstängd från början, så slå på den för rätt organisationsenheter eller grupper. En typisk uppsättning identifierar personer via primär e-postadress, så planera för namnbyten och återanvända adresser.
Checklista för testning
Kontrollera följande i ett privat webbläsarfönster före driftsättning:
- En befintlig användare loggar in med start i LMS:et, och igen från app-rutan.
- En ny användare på din domän får ett konto med rätt roll.
- Den som inte är tilldelad applikationen nekas.
- Den som ligger utanför dina tillåtna domäner nekas.
- E-post, förnamn och efternamn kommer fram korrekt.
- En administratör kan fortfarande ta sig in via återställningsvägen.
Vanliga fallgropar
Klockavvikelse
Om IdP:ns och LMS:ets klockor avviker mer än vad LMS:et tolererar avvisas korrekta assertions som ännu inte giltiga eller redan utgångna. Det drabbar mest egendrivna identitetsservrar, så håll deras klockor synkroniserade.
Byte av certifikat
IdP:ns signeringscertifikat går ut, och om LMS:et inte litar på ersättaren misslyckas varje inloggning på en gång. Lägg utgångsdatumet i kalendern. Om ditt LMS kan lita på två certifikat lägger du först till det nya där och aktiverar det sedan hos IdP:n; annars byter du båda sidor samtidigt vid en lugn tidpunkt. Testa direkt.
Attributmappning
Attributnamn matchas vanligtvis exakt: ett LMS som väntar sig email godtar inte Email. Kontrollera identifieraren också. Ett transient NameID ändras vid varje session och en e-postadress kan ändras; ett persistent NameID eller ett oföränderligt ID-attribut är stabilt. Om personer matchas på e-post, arkivera kontot för den som slutar innan adressen tilldelas någon annan.
E-postdomäner som inte stämmer
Kataloger innehåller ofta personer vars inloggningsnamn inte är deras e-postadress, entreprenörer på andra domäner och personal från uppköpta bolag som fortfarande ligger kvar på gamla domäner. Om LMS:et begränsar konton till vissa domäner nekas de. Lista varje domän före driftsättning.
Så gör Acadenix
SAML SSO ingår i Gold-abonnemanget, med steg-för-steg-guider för Entra ID, Okta och Google Workspace.
- Testa, aktivera sedan. Du sparar din IdP:s uppgifter som ett utkast, kör Test configuration (testa konfigurationen) genom att logga in hos din leverantör, och först därefter aktiverar du. Ett saknat e-postclaim rapporteras tillsammans med de claim-namn som din leverantör faktiskt skickade.
- Stegvisa ändringar. Ett nytt certifikat eller en ny tenant läggs in som en konfigurationsuppdatering, och den nuvarande konfigurationen fortsätter fungera tills du aktiverar den.
- JIT inom dina domäner. Den som saknar konto får ett deltagarkonto vid första inloggningen, men bara om personens e-postadress finns bland din organisations registreringsdomäner, och du kan stänga av det. När någon som redan har ett Acadenix-konto loggar in via din IdP för första gången mejlar Acadenix personen en engångskod för att bekräfta kopplingen. Det sker en gång per person.
- Båda vägarna in. Folk startar från din inloggningssida, som kan skicka dem direkt till din IdP eller visa en knapp, eller från rutan i My Apps, Okta eller Google.
- En anslutning, en organisation. En SAML-anslutning ärvs inte av organisationerna under sin ägare, vilket är viktigt för koncerner med många arbetsplatser.
- En återställningsväg. Om din IdP ligger nere kan administratörer fortfarande logga in med en engångskod via e-post, och det kan inte stängas av.
Vid sidan av SAML kan folk logga in med en kod via e-post eller med ett Google-, Microsoft- eller LinkedIn-konto. Läs mer på vår säkerhetssida.
Sammanfattning
- Utbyt entity ID:n, ACS URL och metadata, och mappa sedan en stabil identifierare och en verifierad e-postadress.
- Begränsa just-in-time-konton till dina egna domäner och den lägsta rollen.
- Testa båda inloggningsflödena, nekandena och återställningsvägen före driftsättning.
- Lägg certifikatens utgångsdatum i kalendern och arkivera LMS-konton för dem som slutar.
Vill du koppla Acadenix till din identitetsleverantör? Jämför abonnemang på vår prissida eller prata med oss om din uppsättning.
