OIDC-MFA-verifiering
Vad det här är
När en användare loggar in i fremforge via din organisations IdP (Entra, Okta, Google Workspace, Authentik, Keycloak, …) returnerar IdP:n en OIDC-ID-token. Den token bär ett amr-anspråk (Authentication Methods References, RFC 8176) som listar de autentiseringsfaktorer som användes vid just den här inloggningen, till exempel ["pwd","mfa"], ["fido"] eller ["otp"].
fremforge kan:
- Begära en viss autentiseringskontext från din IdP vid inloggningen genom att skicka OIDC-parametern
acr_valuesi auktoriseringsbegäran, och - Verifiera att
amr-anspråket i den returnerade ID-token innehåller ett värde som intygar MFA innan sessionen får starta.
Tillsammans gör det “vi litar på att din IdP gjorde MFA” till “vi har kryptografiskt verifierat att din IdP gjorde MFA i det här steget, varje gång”.
Varför det här ersätter “Trust IdP MFA”
Den äldre kryssrutan Trust IdP MFA var ett intygande: operatören bekräftar att deras IdP kräver MFA, och fremforge hoppar över sin egen MFA-fråga för användare från den källan. fremforge hade inget sätt att verifiera intygandet. Om IdP:ns MFA-policy var felkonfigurerad eller tillfälligt lättades upp loggade användarna in utan MFA, och fremforge fick aldrig veta det.
Den nya vägen, OIDC-MFA-verifiering, granskar amr-anspråket i varje ID-token och avvisar inloggningar som inte intygar MFA. Det är IdP:ns signatur på ID-token som gör det tillförlitligt: en inloggning som når fremforge med amr=["mfa"] bevisar kryptografiskt att din IdP utförde MFA för exakt den här sessionen, inte att “policyn säger att den borde ha gjort det”.
Kryssrutan Trust IdP MFA har tagits bort. OIDC-MFA-verifiering är alltid påslagen för varje OIDC-inloggningskälla och kan inte stängas av.
Ställ in verifiering
- Hitta kortet för IdP:ns autentiseringskälla på organisationens administrationssida SSO (
<your-org>/_admin/sso). - Fäll ut panelen OIDC-MFA-verifiering. Verifieringen är alltid påslagen, så det finns inget att kryssa i.
- Välj ett Leverantörsförval som motsvarar din IdP. Förvalet anger de
acr_valuessom vi skickar till IdP:n vid inloggning. - Spara.
När du har sparat börjar den patchade Forgejo-körmiljön kontrollera amr vid varje callback från den här källan. Den första inloggningen efter ändringen är kanariefågeln: kontrollera att den lyckas och rulla sedan ut till resten av organisationen.
Leverantörsförval
| Leverantör | Förval | acr_values som skickas | Vad IdP:n behöver |
|---|---|---|---|
| Microsoft Entra ID | entra_c2 | c2 | En Conditional Access-policy som kopplar en autentiseringskontext till MFA. Apple/Mac-användare: installera Microsoft Authenticator om du inte redan har en registrerad faktor. |
| Microsoft Entra ID | entra_c3 | c3 | Samma som c2 plus smartkort/klientcertifikat. Använd för reglerade tenants (myndigheter, bank). |
| Okta | okta_phr | phr | En Authentication Policy som kräver en nätfiskeresistent faktor (FIDO2, WebAuthn). |
| Okta | okta_phrh | phrh | Samma som phr men hårdvarubunden: YubiKey eller plattformsautentiserare. Den starkaste ACR:en i Okta. |
| Google Workspace | google_mfa | urn:google:multi_factor | Tvåstegsverifiering som krävs i administrationskonsolen. |
| Generisk OIDC | tomt | (inget) | Verifiera bara att amr innehåller ett MFA-värde. Använd det när din IdP inte exponerar ACR-konfiguration men skickar MFA i amr. |
| Anpassad | ditt värde | (det du skriver) | Allt som inte finns i listan: Keycloak, PingFederate, ForgeRock, Authelia, … |
Vilka MFA-värden vi godtar
Enligt RFC 8176 plus de vanliga leverantörsutökningarna godtas följande amr-värden som intygande om MFA:
mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba
En inloggning godtas när arrayen amr innehåller minst ett av dem. En inloggning med enbart amr=["pwd"] avvisas (lösenord utan MFA).
Alternativt, när du har konfigurerat ett leverantörsförval, godtas en inloggning också när ID-tokens acr-anspråk är exakt lika med förvalets värde, till exempel acr=c2 i Entra. Det är den väg de flesta uppsättningar med Entra och Okta använder, eftersom leverantörerna oftast returnerar ett rikare acr än amr.
Testa verifieringen
En säker utrullning: slå på verifiering för en autentiseringskälla (en tenant) och låt en testanvändare logga in en gång. Om inloggningen lyckas har du verifierat att IdP:ns kedja av anspråk stämmer med vad vi förväntar oss. Om inloggningen avvisas med meddelandet “MFA was not asserted” returnerade IdP:n något som vi inte kände igen. Vanliga orsaker:
- Entra: Conditional Access-policyn är inte kopplad till den applikation som den här autentiseringskällan representerar. Kontrollera i Entra-portalen → Conditional Access → Policies att appen ingår i omfånget.
- Okta: Authentication Policy för OIDC-applikationen är satt till “Any factor type allowed”. Skärp den till en nätfiskeresistent faktor.
- Google Workspace: Tvåstegsverifiering är konfigurerad per användare och inte påtvingad i hela organisationen. Sätt tillämpningen för organisationsenheten till “On”.
Posten i granskningsloggen för en avvisad inloggning (åtgärden tenant.auth_policy.oidc_mfa.rejected) innehåller exakt de amr- och acr-värden som IdP:n returnerade. Kopiera in dem i ett supportärende om du behöver hjälp med felsökningen.
Granskningsspår
Varje gång inställningarna för OIDC-MFA-verifiering ändras för en autentiseringskälla skapas en granskningshändelse med åtgärden sso.auth-source.oidc-mfa-config.update, med föregående och nya värden för både acr_values och require_oidc_amr_mfa, samt aktören och tidsstämpeln.
Varje inloggning som avvisas för att amr inte intygade MFA skapar tenant.auth_policy.oidc_mfa.rejected med källans namn, aktörens e-postadress och de amr/acr som IdP:n returnerade, så att operatören kan felsöka avvikelser i konfigurationen innan de hopar sig.
Relaterat
- Autentiseringspolicy: bredare kontroller av säkerhetsläget (SSH avstängt, längsta livslängd för PAT, signerade commits, …).
- Genomgång av SSO-uppsättningen: den första kopplingen av en OIDC-autentiseringskälla. Gör det först; OIDC-MFA-verifiering är härdningssteget när den grundläggande kopplingen fungerar.
- Vad MFA-semantiken innebär: fremforges övergripande hållning till MFA och hur MFA hos IdP:n samverkar med TOTP/WebAuthn i Forgejo.