Opsæt Microsoft Entra ID

Denne guide fører dig fra en tom Azure-konfiguration til fuldt fungerende Microsoft SSO med rollebaseret adgang i Ressourcify. Guiden dækker alt — app-registrering, grupper, token-konfiguration og verificering.

Forudsætninger

Inden du går i gang, skal du have:

• Azure-adgang — rollen Application Administrator, Cloud Application Administrator eller Global Administrator i Microsoft Entra ID
• Ressourcify-adgang — ORG_ADMIN-rollen i Ressourcify (eller adgang til miljøvariabler på serveren)
• Produktions-URL — det domæne Ressourcify kører på, f.eks. https://app.ressourcify.dk

Overblik

Ressourcify taler med Entra ad to adskilte veje. De stiller hver sine krav til API-tilladelser, og det er den hyppigste kilde til fejl i opsætningen.

Vej 1 — Login (altid aktiv). Roller udledes af groups-claim i Microsofts JWT-token. Der foretages ingen Graph API-kald.

Bruger klikker "Log ind med Microsoft"
  └─▶ Microsoft Entra ID validerer brugeren
        └─▶ Token udstedes med groups-claim (gruppe-ID'er)
              └─▶ NextAuth modtager token
                    └─▶ Ressourcify mapper gruppe-ID'er til roller
                          └─▶ Bruger lander på dashboard med korrekt rolle

Vej 2 — Brugersynkronisering (valgfri). Et baggrundsjob henter medlemmerne af dine grupper via Microsoft Graph og opretter brugerne i Ressourcify, før de har logget ind første gang. Den vej kræver app-tilladelser med admin consent.

Sync startes (manuelt eller natligt)
  └─▶ Ressourcify henter et app-token (client credentials)
        └─▶ Graph: hent medlemmer af de fire grupper
              └─▶ Brugere oprettes/opdateres (navn, e-mail, aktiv/spærret)
                    └─▶ Roller tildeles efter gruppemedlemskab

Opsætning

Hvorfor kræver synkronisering User.Read.All?

User.Read.All giver på papiret læseadgang til alle brugerprofiler i tenant'en. Det er et rimeligt spørgsmål at stille ved en sikkerhedsgodkendelse, så her er begrundelsen og de afgrænsninger der findes.

Hvad Ressourcify faktisk kalder. Synkroniseringen kalder ét endpoint, GET /groups/{id}/members — én gang pr. konfigureret gruppe. Den kalder aldrig /users og henter derfor aldrig data om nogen, der ikke er medlem af en af de grupper, du selv har oprettet. For de tre rolle-grupper bruges kun medlemmernes ID; navn, e-mail og kontostatus læses udelukkende for medlemmer af Users-gruppen.

Hvorfor tilladelsen alligevel er bredere. Entra kan ikke afgrænse en application-tilladelse til en bestemt gruppe. Administrative Units hjælper heller ikke: en app skal have læserettigheder på tenant-niveau for overhovedet at kunne bruge AU-afgrænsede rolletildelinger. Tilladelsen er altså bredere end anvendelsen, og forskellen kan ikke håndhæves teknisk i Entra — kun i koden.

Hvorfor ikke User.ReadBasic.All? Den findes som application-tilladelse og ville være strammere, men dens "basic profile" er en fast liste: displayName, givenName, mail, photo, surname, userPrincipalName. accountEnabled er ikke med. Uden det felt kan Ressourcify ikke se, om en Entra-konto er spærret, og ville deaktivere samtlige brugere ved hver synkronisering. Den funktion — automatisk at lukke adgangen for fratrådte og spærrede medarbejdere — er netop en af grundene til at bruge synkronisering.

Vil du undgå tilladelsen helt? Undlad at konfigurere synkronisering. Login alene kræver ingen Graph-tilladelser, og brugere oprettes automatisk første gang de logger ind.

Fejlfinding

Næste skridt

• RBAC-matrix — forstå hvilke roller der giver adgang til hvad
• Opret organisation, afdelinger og teams — byg organisationsstrukturen op efter SSO er på plads