OIDC-verifisering av MFA
Hva dette er
Når en bruker logger inn på fremforge via organisasjonens IdP (Entra, Okta, Google Workspace, Authentik, Keycloak, …), returnerer IdP-en et OIDC ID-token. Det tokenet har en amr-claim (Authentication Methods References, RFC 8176) som lister autentiseringsfaktorene som ble brukt ved denne innloggingen, for eksempel ["pwd","mfa"], ["fido"] eller ["otp"].
fremforge kan:
- Be om en bestemt autentiseringskontekst fra IdP-en ved innlogging ved å sende OIDC-parameteren
acr_valuesi autorisasjonsforespørselen, og - Verifisere at
amr-claimen i det returnerte ID-tokenet inneholder en verdi som bekrefter MFA, før sesjonen får starte.
Til sammen gjør dette «vi stoler på at IdP-en din gjorde MFA» om til «vi har kryptografisk verifisert at IdP-en din gjorde MFA på dette steget, hver gang».
Hvorfor dette erstatter «Trust IdP MFA»
Den gamle avkrysningsboksen Trust IdP MFA var en erklæring: operatøren bekrefter at IdP-en håndhever MFA, og fremforge hopper over sin egen MFA-forespørsel for brukere fra den kilden. fremforge hadde ingen måte å verifisere erklæringen på. Hvis MFA-policyen i IdP-en var feilkonfigurert eller midlertidig lempet, ville brukere logge inn uten MFA, og fremforge ville aldri få vite det.
Den nye veien, OIDC MFA verification, undersøker amr-claimen i hvert ID-token og avviser innlogginger som ikke bekrefter MFA. Det er IdP-ens signatur på ID-tokenet som gjør dette til å stole på: en innlogging som kommer til fremforge med amr=["mfa"], beviser kryptografisk at IdP-en din utførte MFA i akkurat denne sesjonen, ikke at «policyen sier at den burde ha gjort det».
Avkrysningsboksen Trust IdP MFA er fjernet. OIDC-verifisering av MFA er alltid slått på for alle OIDC-innloggingskilder og kan ikke slås av.
Sett opp verifisering
- Finn kortet for IdP-ens autentiseringskilde på organisasjonens SSO-side i administrasjonen (
<your-org>/_admin/sso). - Utvid panelet OIDC MFA-verifisering. Verifiseringen er alltid slått på, så det er ingenting å krysse av for.
- Velg en Vendor preset som passer til IdP-en din. Forhåndsinnstillingen bestemmer hvilke
acr_valuesvi sender til IdP-en ved innlogging. - Lagre.
Når innstillingen er lagret, begynner den patchede Forgejo-kjøretiden å sjekke amr ved hver tilbakekalling fra denne kilden. Den første innloggingen etter endringen er kanarien: kontroller at den lykkes, og rull deretter ut til resten av organisasjonen.
Forhåndsinnstillinger per leverandør
| Leverandør | Forhåndsinnstilling | acr_values som sendes | Dette trenger IdP-en |
|---|---|---|---|
| Microsoft Entra ID | entra_c2 | c2 | En Conditional Access-policy som knytter en autentiseringskontekst til MFA. Apple/Mac-brukere: installer Microsoft Authenticator hvis du ikke allerede har en registrert faktor. |
| Microsoft Entra ID | entra_c3 | c3 | Som c2, pluss smartkort / klientsertifikat. Brukes for regulerte kunder (offentlig sektor, bank). |
| Okta | okta_phr | phr | En Authentication Policy som håndhever en phishingresistent faktor (FIDO2, WebAuthn). |
| Okta | okta_phrh | phrh | Som phr, men maskinvarebundet: YubiKey eller plattformautentisering. Den sterkeste ACR-en i Okta. |
| Google Workspace | google_mfa | urn:google:multi_factor | Totrinnsbekreftelse håndhevet i Admin console. |
| Generisk OIDC | tom | (ingen) | Verifiserer bare at amr inneholder en MFA-verdi. Bruk dette når IdP-en ikke tilbyr ACR-oppsett, men sender MFA i amr. |
| Egendefinert | din verdi | (det du skriver inn) | Alt som ikke står på listen: Keycloak, PingFederate, ForgeRock, Authelia, … |
MFA-verdier vi godtar
I tråd med RFC 8176 og de vanlige leverandørutvidelsene godtas disse amr-verdiene som bekreftelse på MFA:
mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba
En innlogging godtas når amr-listen inneholder minst én av disse. En innlogging med bare amr=["pwd"] avvises (passord uten MFA).
Alternativt, når du har satt opp en forhåndsinnstilling, godtas en innlogging også når acr-claimen i ID-tokenet er nøyaktig lik forhåndsinnstillingens verdi, for eksempel acr=c2 i Entra. Det er denne veien de fleste oppsett med Entra og Okta bruker, fordi leverandørene som regel returnerer en rikere acr enn amr.
Teste verifiseringen
En trygg utrulling: slå på verifisering for én autentiseringskilde (én kunde), og la en testbruker logge inn én gang. Hvis innloggingen lykkes, har du bekreftet at IdP-ens claim-kjede samsvarer med det vi forventer. Hvis innloggingen avvises med meldingen «MFA was not asserted», returnerte IdP-en noe vi ikke kjente igjen. Vanlige årsaker:
- Entra: Conditional Access-policyen er ikke bundet til applikasjonen som denne autentiseringskilden representerer. Sjekk Entra-portalen → Conditional Access → Policies → bekreft at appen er omfattet.
- Okta: Authentication Policy for OIDC-applikasjonen er satt til «Any factor type allowed». Stram den inn til en phishingresistent faktor.
- Google Workspace: Totrinnsbekreftelse er satt opp per bruker, ikke håndhevet for hele organisasjonen. Sett håndhevingen for organisasjonsenheten (OU) til «On».
Oppføringen i revisjonsloggen for en avvist innlogging (handlingen tenant.auth_policy.oidc_mfa.rejected) inneholder de nøyaktige amr- og acr-verdiene IdP-en returnerte. Kopier dem inn i en supporthenvendelse hvis du trenger hjelp med feilsøkingen.
Revisjonsspor
Hver gang innstillingene for OIDC-verifisering av MFA endres for en autentiseringskilde, sendes en revisjonshendelse med handlingen sso.auth-source.oidc-mfa-config.update, med forrige og ny verdi for både acr_values og require_oidc_amr_mfa, pluss hvem som gjorde det og tidsstempel.
Hver innlogging som avvises fordi amr ikke bekreftet MFA, sender tenant.auth_policy.oidc_mfa.rejected med kildenavnet, aktørens e-postadresse og amr/acr slik IdP-en returnerte dem, slik at operatøren kan feilsøke feil i oppsettet før de hoper seg opp.
Relatert
- Autentiseringspolicy: bredere sikkerhetsinnstillinger (SSH slått av, maksimal levetid for PAT, signerte commits, …).
- Gjennomgang av SSO-oppsett: det første oppsettet av en OIDC-autentiseringskilde. Gjør dette først; OIDC-verifisering av MFA er innstrammingen etter at det grunnleggende oppsettet virker.
- Hva MFA betyr: fremforges samlede tilnærming til MFA, og hvordan MFA i IdP-en spiller sammen med TOTP/WebAuthn i Forgejo.