OIDC-MFA-verificering
Hvad det er
Når en bruger logger ind på fremforge via din organisations IdP (Entra, Okta, Google Workspace, Authentik, Keycloak, …), returnerer IdP’en et OIDC-ID-token. Tokenet indeholder et amr-claim (Authentication Methods References, RFC 8176), der lister de godkendelsesfaktorer, der blev brugt ved dette login, f.eks. ["pwd","mfa"], ["fido"] eller ["otp"].
fremforge kan:
- Bede din IdP om en bestemt godkendelseskontekst ved login ved at sende OIDC-parameteren
acr_valuesmed i autorisationsforespørgslen, og - Verificere, at
amr-claimet i det returnerede ID-token indeholder en værdi, der bekræfter MFA, før sessionen får lov at starte.
Tilsammen gør det “vi stoler på, at din IdP lavede MFA” til “vi har kryptografisk verificeret, at din IdP lavede MFA på dette hop, hvert eneste hop”.
Hvorfor det erstatter “Trust IdP MFA”
Det gamle afkrydsningsfelt Trust IdP MFA var en erklæring: operatøren bekræfter, at deres IdP håndhæver MFA, og fremforge springer sin egen MFA-prompt over for brugere fra den kilde. fremforge havde ingen mulighed for at verificere erklæringen. Hvis IdP’ens MFA-politik var forkert sat op eller midlertidigt lempet, ville brugerne logge ind uden MFA, og fremforge ville aldrig opdage det.
Den nye vej, OIDC-MFA-verificering, undersøger amr-claimet i hvert ID-token og afviser logins, der ikke bekræfter MFA. Det er IdP’ens signatur på ID-tokenet, der gør det troværdigt: et login, der lander på fremforge med amr=["mfa"], beviser kryptografisk, at din IdP udførte MFA på netop denne session, ikke blot at “politikken siger, at den burde have gjort det”.
Afkrydsningsfeltet Trust IdP MFA er fjernet. OIDC-MFA-verificering er altid slået til for alle OIDC-loginkilder og kan ikke slås fra.
Sådan sætter du verificeringen op
- Find kortet for IdP’ens autentificeringskilde på din organisations SSO-administrationsside (
<your-org>/_admin/sso). - Fold panelet OIDC-MFA-verificering ud. Verificeringen er altid slået til, så der er intet at sætte flueben ved.
- Vælg det Leverandørpreset, der passer til din IdP. Presettet bestemmer de
acr_values, vi sender til IdP’en ved login. - Gem.
Når det er gemt, begynder den patchede Forgejo-runtime at kontrollere amr ved hvert callback fra denne kilde. Det første login efter ændringen er kanariefuglen: tjek, at det lykkes, og rul det derefter ud til resten af organisationen.
Leverandørpresets
| Leverandør | Preset | Sendte acr_values | Hvad IdP’en skal have |
|---|---|---|---|
| Microsoft Entra ID | entra_c2 | c2 | En Conditional Access-politik, der knytter en godkendelseskontekst til MFA. Apple/Mac-brugere: installér Microsoft Authenticator, hvis du ikke allerede har en registreret faktor. |
| Microsoft Entra ID | entra_c3 | c3 | Som c2 plus smartcard/klientcertifikat. Brug det til regulerede tenants (offentlig sektor, bank). |
| Okta | okta_phr | phr | En Authentication Policy, der håndhæver en phishing-resistent faktor (FIDO2, WebAuthn). |
| Okta | okta_phrh | phrh | Som phr, men hardwarebundet: YubiKey eller platformens indbyggede authenticator. Oktas stærkeste ACR. |
| Google Workspace | google_mfa | urn:google:multi_factor | Totrinsbekræftelse håndhævet i Admin-konsollen. |
| Generisk OIDC | tom | (ingen) | Verificér blot, at amr indeholder en MFA-værdi. Brug det, når din IdP ikke udstiller ACR-opsætning, men udsender MFA i amr. |
| Brugerdefineret | din værdi | (det, du skriver) | Alt, der ikke er på listen: Keycloak, PingFederate, ForgeRock, Authelia, … |
Hvilke MFA-værdier vi accepterer
Ifølge RFC 8176 plus de almindelige leverandørudvidelser accepteres følgende amr-værdier som bekræftelse af MFA:
mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba
Et login accepteres, når amr-arrayet indeholder mindst én af dem. Et login med kun amr=["pwd"] afvises (adgangskode uden MFA).
Når du har valgt et leverandørpreset, accepteres et login desuden, når ID-tokenets acr-claim er præcis lig med presettets værdi, f.eks. acr=c2 hos Entra. Det er den vej, de fleste Entra- og Okta-opsætninger bruger, fordi leverandørerne typisk returnerer et mere udførligt acr end amr.
Sådan tester du verificeringen
En sikker udrulning: slå verificeringen til på én autentificeringskilde (én tenant), og lad en testbruger logge ind én gang. Lykkes login, har du verificeret, at IdP’ens kæde af claims svarer til det, vi forventer. Afvises login med beskeden “MFA was not asserted”, returnerede IdP’en noget, vi ikke genkendte. Typiske årsager:
- Entra: Conditional Access-politikken er ikke knyttet til den applikation, som denne autentificeringskilde repræsenterer. Gå til Entra-portalen → Conditional Access → Policies, og bekræft, at appen er omfattet.
- Okta: Authentication Policy for OIDC-applikationen står til “Any factor type allowed”. Stram den op til en phishing-resistent faktor.
- Google Workspace: Totrinsbekræftelse er sat op pr. bruger og ikke håndhævet for hele organisationen. Sæt håndhævelsen for organisationsenheden (OU) til “On”.
Posten i revisionsloggen for et afvist login (handlingen tenant.auth_policy.oidc_mfa.rejected) indeholder de præcise amr- og acr-værdier, som IdP’en returnerede. Kopiér dem ind i en supportsag, hvis du har brug for hjælp til fejlfindingen.
Revisionsspor
Hver ændring af en autentificeringskildes indstillinger for OIDC-MFA-verificering udløser en revisionshændelse med handlingen sso.auth-source.oidc-mfa-config.update med de tidligere og nye værdier for både acr_values og require_oidc_amr_mfa samt aktøren og tidspunktet.
Hvert login, der afvises, fordi amr ikke bekræftede MFA, udløser tenant.auth_policy.oidc_mfa.rejected med kildens navn, aktørens e-mail og de amr/acr-værdier, IdP’en returnerede, så operatøren kan finde fejl i opsætningen, før de hober sig op.
Relateret
- Godkendelsespolitik: bredere kontroller af sikkerhedsniveauet (SSH slået fra, maksimal levetid for PAT’er, signerede commits, …).
- Gennemgang af SSO-opsætningen: den første opsætning af en OIDC-autentificeringskilde. Gør det først; OIDC-MFA-verificering er hærdningstrinnet, når den grundlæggende opsætning virker.
- Hvad MFA betyder: fremforges overordnede tilgang til MFA, og hvordan MFA hos IdP’en spiller sammen med TOTP/WebAuthn i Forgejo.