Multi-factor authenticatie (MFA of 2FA) betekent dat een gebruiker naast een wachtwoord een tweede bewijs van identiteit levert (bijv. app-token, hardware-token, sms) voordat toegang wordt verleend, en SURFconext ondersteunt het toepassen van MFA zoals die al op de eigen Identity Provider van een instelling is ingericht (bijv. Microsoft/Azure MFA, NetIQ) voor diensten die via SURFconext ontsloten worden.

Wat is het

Het is mogelijk op de eigen identity provider (IdP), bijvoorbeeld ADFS of EntraID van Microsoft, NetIQ, SimpleSAMLphp etc, multi-factor authenticatie in te richten. Met policy's kan bepaald worden voor welke diensten (SP's of RP's) MFA vereist is. Door Microsoft IdPs (ADFS of EntraID) worden alle diensten achter SURFconext als één koppeling gezien. Als het niet wenselijk is om MFA te vereisen voor alle diensten achter SURFconext, kan SURFconext de IdP alleen voor specifieke dienesten om MFA vragen. Die werkt ook voor andere IdPs dan die van Microsoft.

SURFconext kan voor een door de instelling bepaalde set SP's een signaal naar een IdP sturen dat MFA vereist is voor die set SP's. Zo kan de IdP vervolgens aan de gebruiker een token vragen. Bij terugkeer van de gebruiker van de IdP verifieert SURFconext dat dit werkelijk gebeurd is. Indien niet, krijgt de gebruiker een foutmelding en kan niet door naar de dienst. SURF vindt leveranciersonafhankelijkheid een belangrijke waarde. De functie is dan ook generiek opgezet volgens de SAML2.0-protocolspecificatie en in principe toepasbaar met zoveel mogelijk verschillende identity provider-producten en MFA-oplossingen. Het werkt met het aanbod van Microsoft (EntraID en ADFS), maar ook hebben we implementaties met NetIQ en met Vasco tokens bijvoorbeeld.

Uitleg over deze functionaliteit in een video van één minuut

Er is een best practice waarin twee instellingen vertellen hoe ze dit hebben ingezet.

Hoe werkt het

Als een gebruiker wil inloggen op een SP, stuurt deze SP een authenticatieverzoek naar SURFconext. SURFconext toont het Where Are You From-scherm en de gebruiker selecteert de instelling.

SURFconext houdt voor iedere IdP een lijst bij met SP's waarvoor op die IdP MFA moet worden toegepast. Staat de SP in de lijst van de gekozen IdP, dan stuurt SURFconext in het AuthnRequest naar de IdP een speciale waarde mee in het SAML-element "RequestedAuthnContext", zodat de IdP weet dat er om MFA gevraagd moet worden.

De meest gebruikte waarden die we op dit moment kunnen sturen zijn https://refeds.org/profile/mfa (generiek bruikbaar, gestandaardiseerd) of http://schemas.microsoft.com/claims/multipleauthn (vendorspecifiek voor Microsoft-producten).

De IdP laat de gebruiker inloggen en vraagt om de tweede factor (die de instelling zelf regelt), en stuurt vervolgens een SAML Assertion terug naar SURFconext met de gebruikersattributen en, bij succes, een bevestiging dat MFA heeft plaatsgevonden via dezelfde waarde als in RequestedAuthnContext, nu in het element AuthnContextClassRef, of, specifiek bij Microsoft ADFS/EntraID, in het aparte attribuut http://schemas.microsoft.com/claims/authnmethodsreferences. SURFconext controleert dit element (of attribuut): bij bevestiging gaat de gebruiker door naar de SP, zo niet dan krijgt de gebruiker een foutmelding en wordt de toegang geweigerd.

Wat moet een SP doen

Niets. Het werkt met alle SP's/RP's gekoppeld aan SURFconext.

Als de instelling een (test/accepatie) IdP heeft aangesloten op SURFconext TEST, kan de functionaliteit ook daar getest worden met SP's die zijn aangesloten op SURFconext TEST.

Wat moet een IdP doen

Afstemming met het SURFconext-team vooraf is niet nodig; alle IdP's die dit willen kunnen het in gebruik nemen. De functionaliteit behoort bij het standaard aanbod van SURFconext en vereist geen abonnement of tarief.

Voorop staat dat de IdP zelf een MFA-oplossing (zoals Microsoft MFA, NetIQ of anderszins) geimplementeerd heeft, en zorgt dat alle gebruikers die op een waar MFA voor verplicht is ook een MFA middel hebben. We gaan er vanuit dat dit al operationeel is.

In het geval van Microsoft MFA in combinatie met ADFS moet de IdP de ADFS configuratie aanpassen om het attribuut "http://schemas.microsoft.com/claims/authnmethodsreferences" door te geven aan SURFconext. Hiervoor hebben we een handleiding: Toevoegen attribuut AuthnMethodsReferences aan ADFS.

Voor Microsoft EntraID IdP's hoeft er geen extra attribuut vrijgegeven te worden, voor IdP's van andere leverancies is dit normaal gesproken ook niet nodig.

MFA vereisen voor diensten

MFA stel je in via het IdP-dasboard

Als aan de basisvoorwaarden voldaan is, kan de instelling aan SURFconext aangeven voor welke diensten ze MFA vereist is. Dit doet de SURFconext-verantwoordelijke via het SURFconext IdP-dashboard. Zoek de dienst op en kies onder de tab "Extra opties", subtab "MFA" de juiste waarde.

Indien je wilt testen of het goed werkt, kun je bijvoorbeeld deze optie laten inschakelen op de dienst SURFconext Demo SP.

De configuratie voor wel of geen MFA geldt per dienst, dus "MFA is vereist voor alle gebruikers op SP A". Het is dus niet mogelijk om dit bijvoorbeeld af te dwingen voor "alleen medewerkers op dienst A, studenten niet". Dit komt omdat we bij het uitsturen van het verzoek aan de IdP de gebruiker nog niet geauthenticeerd is, en we daarom op dat moment nog niet weten of het een student of medewerker betreft. Microsoft-producten zullen ook geen conditional access policy's toepassen op deze logins.

MFA voor alle bijna alle diensten

SURFconext adviseert voor alle logins op diensten achter SURFconext met (een vorm van) MFA te gebruiken, en alleen uitzonderingen daar waar dit niet gewenst is, bijvoorbeeld voor toetsapplicaties. Dit is mogelijk, ook als de instelling EntraID met Microsoft MFA gebruikt. Lees hier meer over op SURFconext en categorisch MFA instellen.