Pålogging med Single Sign-On (SSO) + Brukerprovisjonering
Denne veiledningen beskriver hvordan dere forbereder organisasjonen på dette, hvordan prosessen gjennomføres, og hvilke risikofaktorer dere bør vurdere.
Innhold
LAFT kan integreres med Microsoft Azure AD (nå Microsoft Entra ID) for Single Sign-On (SSO). Dette gjør at alle brukere autentiseres via Microsoft i stedet for å ha separate passord eller valgfri SSO-innlogging.
Når SSO aktiveres, gjelder det for alle brukere i organisasjonen, inkludert eksterne brukere og leverandører som skal ha tilgang til LAFT.
SSO vil også bli tilgjengelig i LAFT-appen i løpet av siste halvdel av 2026. |
Automatisk brukerprovisjonering via Microsoft Entra (SCIM)
Ved å benytte seg av denne muligheten kan alt av brukeradministrasjon styres fra Entra av de med admin-tilgang der. Her er en oversikt over hvordan det fungerer:
LAFT støtter snart brukerprovisjonering via Microsoft Entra. Det betyr at brukere kan opprettes automatisk i LAFT, basert på oppsett i Entra. Dette er spesielt nyttig for organisasjoner med mange brukere, eller der ansatte kommer og går jevnlig.
Slik fungerer det
Når provisjonering er satt opp, vil brukere som oppfyller vilkårene i Entra bli opprettet automatisk i LAFT. Du slipper å registrere dem manuelt.
Forutsetning: SSO må være aktivert i LAFT før provisjonering kan brukes.
Oppsett i Entra (gjøres av Entra-admin)
I Microsoft Entra må dere:
- Konfigurere SCIM-provisjonering mot LAFT i Entra-applikasjonen.
- Definere hvilke brukere som skal provisioneres, for eksempel ved hjelp av grupper eller attributter/tags.
- Sørge for at kun ønskede brukere er i scope. Brukere som ikke er i scope, opprettes ikke i LAFT.
⚠️ Det er Entra-admin sitt ansvar å styre hvem som provisioneres. Sjekk dette nøye før dere aktiverer.
Oppsett i LAFT (gjøres av LAFT-admin)
Under Administrasjon → Systembrukere → Entra SCIM-innstillinger kan dere konfigurere:
- Rolle for provisionerte brukere Velg hvilken rolle brukere skal få når de opprettes via Entra. Standard er Bruker.
-
Bygningstilganger To valg, så velg alternativet som passer deres rutiner best:
- ✅ Gi tilgang til alle bygg automatisk
- 🔧 Sett bygningstilganger manuelt etter at brukeren er opprettet
Oversikt over Entra-brukere
Vi jobber med nye admin-sider, hvor dere vil få en egen oversiktsstide med brukere som kommer fra Entra. Denne er ikke tilgjengelig enda, men vil bli tilgjengelig ila. 2026. Her er hvordan det vil bli:
Under Administrasjon → Systembrukere → Entra-brukere får du en liste over alle brukere som er kommet inn via provisjonering. Her kan du enkelt se hvem som er opprettet, hvilken rolle de har fått, og når de ble lagt til.
Hva skjer når en bruker fjernes i Entra?
Hvis en bruker fjernes fra scope i Entra, vil tilgangen i LAFT deaktiveres automatisk. Dette gjør det enkelt å håndtere offboarding sentralt.
Oppsummering: hvem gjør hva?
| Oppgave | Gjøres av |
|---|---|
| Konfigurere SCIM og velge hvilke brukere som provisioneres | Entra-admin |
| Velge rolle og bygningstilganger for provisionerte brukere | LAFT-admin |
| Følge opp og justere tilganger manuelt ved behov | LAFT-admin |
Overordnet prosess for aktivering
Steg 1 - Intern avklaring ‼️Viktig‼️
Før dere ber LAFT aktivere SSO, bør følgende være avklart:
- Alle interne brukere finnes i Azure AD.
- Alle eksterne brukere/leverandører legges inn i Azure AD dersom de skal ha fortsatt tilgang.
- Roller/tilganger i LAFT er oppdatert eller planlagt.
- Dere har identifisert hvem som administrerer Azure AD hos dere.
Steg 2 - Klargjøring av brukere (valgfritt, men anbefalt)
Brukere kan allerede logge inn med SSO ved å velge "Logg inn med Microsoft" på LAFTs innloggingsside.
Vi anbefaler at dere tester dette i forkant for å sikre at:
- E-postadressen i LAFT = e-postadressen i Azure AD
- Brukerne kommer inn uten problemer
Steg 3 - Import av nye brukere
Hvis dere ønsker at LAFT skal importere brukere før SSO aktiveres:
- Bruk Excel-malen for brukere (last ned her)
- I denne oppgis fornavn, etternavn, e-post, telefonnummer, samt rolle i LAFT
- Send filen til LAFT (support@laft.io)
Steg 4 - Gi beskjed når dere vil aktivere SSO
Når dere er klare gir dere beskjed til LAFT. Vi aktiverer SSO, og effekten er umiddelbar:
🔔 Fra aktiveringstidspunktet må alle brukere logge inn via Microsoft. Det er ingen overlappsperiode.
Steg 5 - Eventuell revert
Hvis uforutsette problemer oppstår, kan LAFT raskt skru av “tvungen pålogging” igjen.
Brukertyper og hva dere må gjøre
Interne brukere
Disse er normalt allerede i Azure AD. Dere må:
- Bekrefte at e-postadresser i LAFT og Azure matcher
- Teste at SSO fungerer for et utvalg brukere
Roller og nivåer
Roller i LAFT påvirker hvilke funksjoner brukeren får tilgang til. Rollen i LAFT styres fortsatt i LAFT, ikke i Azure AD. Når dere sender Excel-importfilen, må hver bruker ha tildelt riktig rolle.
Eksterne brukere / leverandører
Dette punktet er kritisk. Når SSO er aktivert, gjelder Microsoft-innlogging for alle, uansett tilknytning.
Derfor må dere:
- Legge inn eksterne brukere som gjestebrukere/Guest Users i Azure AD (eller tilsvarende organisasjonsrutine)
- Sikre at de får tildelt passende sikkerhetsnivå i deres Microsoft-miljø
- Eventuelt informere leverandører om den nye innloggingsmetoden
Hvis eksterne brukere ikke ligger i Azure AD, mister de tilgang fra det øyeblikket SSO aktiveres.
Utfordringer og ting å være obs på
Generelle utfordringer
- Forskjellig e-postadresse i LAFT og Azure AD → brukere kommer ikke inn.
- Eksterne brukere glemmes i forberedelsen. Manglende kommunikasjon internt før aktivering.
- Brukere med flere Microsoft-kontoer (jobb/privat) opplever forvirring.
- Azure AD-policyer (MFA, Conditional Access, IP-begrensninger) kan hindre noen brukere.
Teknisk avhengighet mot Microsoft
Når SSO er aktivert, er LAFT avhengig av at:
- Azure AD fungerer som normalt
- Deres Microsoft-policyer tillater innlogging fra eksterne og interne brukere
- Eventuelle leverandøravtaler med Microsoft tillater Guest-access
Overgang og endring (innfasing/utfasing)
Det finnes ingen overlapp. Aktiveringstidspunkt = alle må logge inn via Microsoft.
Anbefalt praksis før aktivering:
- Be brukere i en periode om å logge inn valgfritt med “Logg inn med Microsoft”
- Følg med på om noen ikke får logget inn
- Korriger feil i Azure AD før dere aktiverer tvungen SSO
Sikkerhet, kommunikasjonssystem og leverandøravtaler
Sikkerhet
- SSO styrker sikkerheten ved å samle autentisering i Azure AD.
- MFA og betinget tilgang styres sentralt hos dere.
- Ingen passord lagres i LAFT når SSO er på.
Kommunikasjonssystem
Internt bør dere:
- Informere alle ansatte om endringen
- Informere alle leverandører/eksterne
- Utpeke en intern kontaktperson som håndterer Azure AD-spørsmål fra ansatte
Leverandøravtaler
- Sjekk at deres Microsoft-lisens dekker Guest Users
- Sjekk eventuelle avtaler med leverandører som krever tilgang i LAFT
- Oppdater interne rutiner for onboarding/offboarding av ansatte - dette vil nå knyttes til Azure AD
Risikofaktorer + løsninger
| Risiko | Konsekvens | Tiltak |
|---|---|---|
| E-post i LAFT er ikke lik e-post i Azure AD | Bruker får ikke logget inn | Gjennomfør kontroll av alle kontoer før aktivering |
| Eksterne brukere mangler i Azure | Leverandører mister tilgang | Legg inn eksterne brukere som gjester i Azure AD |
| Strenge Azure-policyer | Enkelte blokkeres | Test brukere fra ulike roller før aktivering |
| Mangelfull intern info | Brukerstøttebelastning | Informer tydelig i forkant |
| Feil rolle i LAFT | Manglende tilganger | Oppdater roller før aktivering |
| Microsoft-tjenester nede | Ingen får logget inn | Avklar interne beredskapsrutiner |
| Privat Microsoft-konto overtar innlogging | Forvirring ved pålogging | Be brukere logge ut privat konto før første innlogging |
Sjekkliste
✔ Før aktivering:
✔ Ved aktivering:
✔ Etter aktivering: