OIDC-MFA-verificatie
Wat dit is
Logt een gebruiker bij fremforge in via de IdP van je organisatie (Entra, Okta, Google Workspace, Authentik, Keycloak, …), dan stuurt de IdP een OIDC-ID-token terug. Dat token bevat een amr-claim (Authentication Methods References, RFC 8176) met de authenticatiefactoren die bij deze inlog zijn gebruikt, bijvoorbeeld ["pwd","mfa"], ["fido"] of ["otp"].
fremforge kan:
- Bij het inloggen een specifieke authenticatiecontext bij je IdP aanvragen door de OIDC-parameter
acr_valuesmee te sturen in het autorisatieverzoek, en - Controleren dat de
amr-claim in het teruggestuurde ID-token een waarde bevat die MFA bevestigt, voordat de sessie mag beginnen.
Samen maakt dit van “we vertrouwen erop dat je IdP MFA heeft gedaan” een “we hebben cryptografisch geverifieerd dat je IdP bij deze stap MFA heeft gedaan, bij elke stap”.
Waarom dit “Trust IdP MFA” vervangt
Het oude selectievakje Trust IdP MFA was een verklaring: de operator bevestigt dat de IdP MFA afdwingt, en fremforge slaat zijn eigen MFA-vraag over voor gebruikers uit die bron. fremforge kon die verklaring op geen enkele manier controleren. Was het MFA-beleid van de IdP verkeerd ingesteld of tijdelijk versoepeld, dan logden gebruikers zonder MFA in en merkte fremforge daar niets van.
De nieuwe route OIDC-MFA-verificatie bekijkt de amr-claim van elk ID-token en weigert inlogs die geen MFA bevestigen. De handtekening van de IdP op het ID-token maakt dit betrouwbaar: een inlog die bij fremforge aankomt met amr=["mfa"] bewijst cryptografisch dat je IdP voor precies deze sessie MFA heeft uitgevoerd, en niet alleen dat “het beleid zegt dat het had gemoeten”.
Het selectievakje Trust IdP MFA is verwijderd. OIDC-MFA-verificatie staat altijd aan voor elke OIDC-inlogbron en kan niet worden uitgezet.
Verificatie instellen
- Zoek op de beheerpagina SSO van je organisatie (
<your-org>/_admin/sso) de kaart van de auth-bron voor de IdP. - Klap het paneel OIDC-MFA-verificatie open. Verificatie staat altijd aan, dus er valt niets aan te vinken.
- Kies een Leverancierspreset die bij je IdP past. De preset bepaalt welke
acr_valueswe bij het inloggen naar de IdP sturen. - Sla op.
Na het opslaan controleert de gepatchte Forgejo-runtime amr bij elke callback vanuit deze bron. De eerste inlog na de wijziging is de proef: controleer dat die lukt en rol het daarna uit naar de rest van de organisatie.
Leverancierspresets
| Leverancier | Preset | Verstuurde acr_values | Wat de IdP nodig heeft |
|---|---|---|---|
| Microsoft Entra ID | entra_c2 | c2 | Een Conditional Access-beleid dat een authenticatiecontext aan MFA koppelt. Apple/Mac-gebruikers: installeer Microsoft Authenticator als je nog geen geregistreerde factor hebt. |
| Microsoft Entra ID | entra_c3 | c3 | Hetzelfde als c2, plus smartcard of clientcertificaat. Voor gereguleerde tenants (overheid, banken). |
| Okta | okta_phr | phr | Een Authentication Policy die een phishingresistente factor afdwingt (FIDO2, WebAuthn). |
| Okta | okta_phrh | phrh | Hetzelfde als phr, maar gebonden aan hardware: een YubiKey of platformauthenticator. De sterkste ACR van Okta. |
| Google Workspace | google_mfa | urn:google:multi_factor | Verificatie in twee stappen, afgedwongen in de Admin-console. |
| Generieke OIDC | leeg | (geen) | Controleert alleen of amr een MFA-waarde bevat. Gebruik dit als je IdP geen ACR-configuratie biedt, maar MFA wel in amr meegeeft. |
| Aangepast | je eigen waarde | (wat je invult) | Alles wat niet in de lijst staat: Keycloak, PingFederate, ForgeRock, Authelia, … |
Welke MFA-waarden we accepteren
Volgens RFC 8176 plus de gangbare uitbreidingen van leveranciers gelden de volgende amr-waarden als bevestiging van MFA:
mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba
Een inlog wordt geaccepteerd als de amr-array minstens één van deze waarden bevat. Een inlog met alleen amr=["pwd"] wordt geweigerd (wachtwoord zonder MFA).
Heb je een leverancierspreset ingesteld, dan wordt een inlog ook geaccepteerd als de acr-claim van het ID-token precies gelijk is aan de waarde van de preset, bijvoorbeeld acr=c2 bij Entra. Dit is de route die de meeste Entra- en Okta-opstellingen gebruiken, omdat leveranciers doorgaans een rijkere acr dan amr teruggeven.
De verificatie testen
Een veilige uitrol: zet verificatie aan op één auth-bron (één tenant) en laat een testgebruiker één keer inloggen. Lukt de inlog, dan heb je geverifieerd dat de claimketen van de IdP overeenkomt met wat wij verwachten. Wordt de inlog geweigerd met de melding “MFA was not asserted”, dan gaf de IdP iets terug dat we niet herkenden. Veelvoorkomende oorzaken:
- Entra: het Conditional Access-beleid is niet gekoppeld aan de applicatie die deze auth-bron vertegenwoordigt. Kijk in de Entra-portal → Conditional Access → Policies en controleer dat de app binnen het bereik valt.
- Okta: de Authentication Policy van de OIDC-applicatie staat op “Any factor type allowed”. Verscherp die naar een phishingresistente factor.
- Google Workspace: verificatie in twee stappen is per gebruiker ingesteld en niet voor de hele organisatie afgedwongen. Zet de afdwinging van de OU op “On”.
De auditlogregel van een geweigerde inlog (actie tenant.auth_policy.oidc_mfa.rejected) bevat de exacte amr- en acr-waarden die de IdP teruggaf. Kopieer ze naar een supportticket als je hulp nodig hebt bij de diagnose.
Audittrail
Bij elke wijziging van de instellingen voor OIDC-MFA-verificatie van een auth-bron ontstaat een auditgebeurtenis met actie sso.auth-source.oidc-mfa-config.update, met de vorige en nieuwe waarden van zowel acr_values als require_oidc_amr_mfa, plus de uitvoerder en het tijdstip.
Elke inlog die wordt geweigerd omdat amr geen MFA bevestigde, levert tenant.auth_policy.oidc_mfa.rejected op, met de naam van de bron, het e-mailadres van de gebruiker en de door de IdP teruggestuurde amr/acr, zodat de operator configuratiefouten kan onderzoeken voordat ze zich opstapelen.
Gerelateerd
- Authenticatiebeleid: bredere beveiligingsinstellingen (SSH uitgeschakeld, maximale geldigheid van PAT’s, ondertekende commits, …).
- Stappenplan voor SSO: de eerste koppeling van een OIDC-auth-bron. Doe dit eerst; OIDC-MFA-verificatie is de verscherping nadat de basiskoppeling werkt.
- Wat MFA hier betekent: de algemene MFA-aanpak van fremforge en hoe MFA aan de kant van de IdP samengaat met TOTP/WebAuthn aan de kant van Forgejo.