Pålogging med Single Sign-On (SSO) + Brukerprovisjonering med Entra
Denne veiledningen beskriver hvordan dere forbereder organisasjonen på dette, hvordan prosessen gjennomføres, og hvilke risikofaktorer dere bør vurdere.
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.
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/roller som skal provisioneres, for eksempel ved hjelp av grupper eller attributter/tags. Les mer om dette i eget avsnitt om provisjonering av brukere under.
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
Hvis Microsoft Entra sier at etablering ikke støttes
Den meldingen betyr ofte at bedriftsappen ikke er en egendefinert (ikke-galleri) app. Automatisk SCIM-oppsett er tilgjengelig når appen opprettes slik Microsoft beskriver for egne SCIM-endepunkter.
I Microsoft Entra admin-senter: Identitet → Programmer → Bedriftsprogrammer.
Velg Nytt program → Opprett eget program.
Velg «Integrer et annet program du ikke finner i galleriet (ikke-galleri)», gi appen et navn (f.eks. LAFT), og opprett den.
Åpne Etablering → Ny konfigurasjon (eller sett modus til Automatisk), lim inn Tenant-URL og hemmelig token fra nedenfor, og Test tilkobling. Stol ikke på gallerioppslag med mindre Microsoft har publisert LAFT med SCIM-kontakt.
Oppsett i LAFT (gjøres enn så lenge av LAFT, men av LAFT-admin på sikt)
Når nye admin-sider blir tilgjengig (ila. 2026): 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 oversiktsside 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
Sette opp roller i Microsoft Entra for provisjonering mot LAFT (teknisk)
LAFT leser ikke Entra-grupper og ikke Entra-katalogroller. LAFT leser app roles på bedriftsappen, sendt over som SCIM roles[].value. Verdien som sendes der, må matche en rolle-mapping som er satt opp i LAFT.
Entra-gruppe → tildelt app role (Value: forvalter)
↓
SCIM roles[].value = "forvalter"
↓
LAFT-mapping: forvalter → Forvalter
Grupper er bare et tildelingsverktøy. Det som faktisk når LAFT, er app role-verdien (Value).
Forutsetninger
Bedriftsappen er en ikke-galleri-app (Identitet → Programmer → Bedriftsprogrammer → Nytt program → Opprett eget program → «Integrer et annet program du ikke finner i galleriet»).
SCIM er satt opp: Tenant URL (https://<HOST>/scim/v2/) og hemmelig token hentet fra Admin → Entra → SCIM-innstillinger i LAFT.
Etableringsmodus er satt til Automatisk, og Test tilkobling er grønn.
Både en Entra-admin og en LAFT-admin (med tilgang til å administrere ScimProvider) er tilgjengelige.
Viktig: Uten punkt 4 i denne veiledningen (attributt-mappingen i Entra) kommer det aldri roller til LAFT, uansett hvor mange app roles som opprettes.
1. Opprett app roles i Entra
App roles ligger på appregistreringen, ikke under «Roller og administratorer» på bedriftsappen – det er katalogroller, og de brukes ikke av LAFT.
Gå til Microsoft Entra-administrasjonssenter → Identitet → Programmer → Appregistreringer.
Åpne LAFT-appen.
Gå til Apprroller → Opprett apprrolle.
Fyll inn feltene som beskrevet i tabellen under.
Felt
Anbefaling
Visningsnavn
Menneskelig, f.eks. Forvalter
Tillatte medlemstyper
Brukere/grupper (må inkludere grupper hvis dere tildeler via gruppe)
Verdi
Stabil nøkkel uten mellomrom, f.eks. forvalter
Beskrivelse
Kort, internt
Aktiver denne apprrollen
På
Gjenta trinnene over for hver LAFT-rolle dere skal styre fra Entra.
Verdi er det eneste LAFT matcher mot. Visningsnavn kan endres uten å ødelegge mappingen. Bruk små bokstaver og ASCII, f.eks. forvalter, bruker, utforer. Matching i LAFT er case-insensitive, men like verdier unngår rot.
Microsoft legger ofte på en innebygd rolle User (Value: User). Den tildeles automatisk alle som får tilgang til appen uten en mer spesifikk rolle, og bør derfor også mappes i LAFT (se avsnittet om fallgruver).
Typisk oppsett:
Entra Value
LAFT-rolle
forvalter
Forvalter
bruker
Bruker
utforer
Utfører
User
Bruker (fallback)
2. Tildel grupper (anbefalt) eller brukere til app roles
Gå til Identitet → Programmer → Bedriftsprogrammer → LAFT-appen.
Åpne Brukere og grupper → Legg til bruker/gruppe.
Velg en sikkerhetsgruppe, f.eks. LAFT-Forvaltere.
Velg apprrollen Forvalter.
Tildel.
Én gruppe per LAFT-rolle er det som skalerer best. Flytt brukere mellom grupper i Entra, så oppdaterer neste synkronisering rollen i LAFT automatisk.
Brukertildeling uten gruppe fungerer også, men blir fort uoversiktlig over tid.
3. Map app roles til SCIM roles
Dette steget glemmes oftest. Entra sender ikke roller til LAFT før attributt-mappingen under er på plass.
Gå til Bedriftsappen → Etablering → Rediger attributtilordning (eller Tilordninger).
Åpne Klargjør Microsoft Entra ID-brukere.
Gå til Vis avanserte alternativer → Rediger attributtliste for customappsso (navnet kan variere).
Hvis attributtet roles mangler: legg det til, i lowercase, merket som flerverdi. Lagre.
Gå tilbake til tilordningene → Legg til ny tilordning, med verdiene i tabellen under.
Felt
Verdi
Tilordningstype
Uttrykk
Uttrykk
AppRoleAssignmentsComplex([appRoleAssignments])
Målattributt
roles
Bruk denne tilordningen
Alltid
Lagre tilordningene og etableringskonfigurasjonen.
AppRoleAssignmentsComplex er inkompatibel med etableringsomfanget «Synkroniser alle brukere og grupper». Bruk «Kun tildelte brukere og grupper».
Hvis Entra klager med feilmeldingen SchemaPropertyCanOnlyAcceptValue eller MultipleGrantsNotSupported: sjekk at roles er satt som flerverdi, og at dere ikke bruker SingleAppRoleAssignment (den tåler bare én rolle).
AssertiveAppRoleAssignmentsComplex([appRoleAssignments]) er et alternativ dersom fjerning av roller ikke slår gjennom. LAFT tåler PATCH mot roles. Se likevel fallgruven lenger ned: umappede resterende verdier kan la en gammel LAFT-rolle stå igjen.
4. Opprett mappingene i LAFT (må gjøres av LAFT enn så lenge, inntil nye admin-sider er tilgjengelige)
Gå til Admin → Entra → SCIM-innstillinger i LAFT.
Velg standardrolle. Denne brukes ved opprettelse av nye brukere når Entra ikke sender noen mappet verdi. Fallback i koden er Bruker (Role::BRUKER).
Under Rolle-mapping (SCIM roles): legg inn én rad per Entra-verdi, som i tabellen under.
Entra-verdi (roles[].value)
LAFT-rolle
Prioritet
forvalter
Forvalter
10
bruker
Bruker
1
User
Bruker
1
Entra-verdien må være identisk med app role Value (case ignoreres, mellomrom trimmes).
Prioritet avgjør hvilken rolle som vinner når en bruker har flere app roles samtidig. Høyest prioritet vinner; lik prioritet brytes med lavest role_id.
Lagre.
Placeholder-teksten i skjemaet er forvalter – det er den verdien testene og hint-teksten i LAFT bruker som eksempel.
5. Hvordan LAFT velger rolle
Logikken under er hentet fra Scim::ResolveRoleFromValues og ScimV2::UsersController#apply_mapped_role! i LAFT.
Situasjon
Resultat
Én mappet verdi
Den rollen brukes
Flere mappede verdier
Rollen med høyest prioritet brukes
Ny bruker, ingen treff i mappingen
Standardrollen brukes
Oppdatering, roller sendt men ingen treff
Eksisterende rolle beholdes
Oppdatering, roles utelatt fra payload
Eksisterende rolle beholdes
Treff, selv med «admin override» satt i LAFT
Rollen overskrives
Admin override i LAFT beskytter bygningstilgang og deaktivering – ikke rolle. En manuell rolleendring i LAFT blir overskrevet ved neste synkronisering dersom Entra sender en mappet verdi.
6. Verifiser
I Entra: gå til Etablering → Klargjør etter behov for én testbruker i gruppen LAFT-Forvaltere.
Sjekk etableringsloggen og bekreft at payloaden inneholder roles med value: "forvalter".
I LAFT: gå til Admin → Entra → Brukere og bekreft at rollen er satt til Forvalter.
Admin → Entra → Log viser role_id ved endring, og kan brukes til å spore hva som skjedde.
Hvis brukeren opprettes med standardrolle: enten sender ikke Entra roles i det hele tatt, mappingen treffer ikke, eller Tenant URL/token peker på feil miljø.
Fallgruver
Fjerning av Forvalter-rolle slår ikke tilbake til Bruker. Hvis Entra etterpå bare sender User, og User ikke er mappet, tolkes roles som «sendt, men uten treff» – LAFT lar da Forvalter-rollen stå. Map alltid den innebygde User-rollen (med lav prioritet) til Bruker.
Flere grupper. En bruker som er medlem av både Forvalter- og Bruker-gruppen, får begge app roles. Prioritet avgjør hvilken som vinner – sett lederroller høyere enn Bruker.
«Synkroniser alle brukere og grupper». Fungerer ikke sammen med AppRoleAssignmentsComplex. Tildel eksplisitt i stedet.
Samme Value to ganger. external_value er unikt per område. Én Entra-verdi skal peke på én LAFT-rolle.
Galleri-app. Automatisk SCIM mot et eget endepunkt krever en ikke-galleri-app. Med en galleri-app vil etablering typisk rapportere at det «ikke støttes».
Bygningstilgang er ikke det samme som rolle. Rollen kommer fra Entra. Bygninger styres separat, enten via «Gi bygningstilgang» for nye brukere, eller manuelt via override – dette er et eget valg på samme innstillingsside.
Anbefalt arbeidsflyt
Lag sikkerhetsgrupper i Entra: én per LAFT-rolle.
Lag app roles med faste Value-nøkler.
Tildel hver gruppe én app role.
Map AppRoleAssignmentsComplex → roles.
Speil de samme nøklene i LAFT, inkludert User → Bruker.
Sett etableringsomfang til tildelte brukere/grupper.
Test med «Klargjør etter behov» før full synkronisering.
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:
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:
Alle eksterne brukere lagt inn som gjester i Azure AD
Roller i LAFT er oppdatert
Test gjort: brukere logger inn via “Logg inn med Microsoft”
Intern informasjon sendt til ansatte
Leverandører varslet
Excel-fil sendt til LAFT hvis import ønskes
✔ Ved aktivering:
Dere gir beskjed til LAFT
LAFT aktiverer SSO
✔ Etter aktivering:
Alle brukere logger inn via Microsoft
Eventuelle feil meldes til Azure AD-ansvarlig hos dere