SURFconext biedt ondersteuning voor het gebruiken van MFA die geconfigureerd is op de instellings-Identity Provider, voor alle diensten (Service Providers) die via SURFconext ontsloten worden. Hiermee kan een instelling die bijvoorbeeld Microsoft/Azure MFA, NetIQ of andere vormen van 2FA gebruikt op de Identity Provider, ook via SURFconext gekoppelde diensten naar wens voorzien van multi-factor authenticatie.
Het gaat hier om het aanroepen van MFA op de identity provider van de instelling zelf, als de instelling dat zelf ingericht heeft op de eigen IdP. Deze functionaliteit heeft geen relatie met de twee-factorauthenticatie-as-a-service zoals aangeboden door SURFsecureID.
Wat is het
Visueel ingesteld? Uitleg over deze functionaliteit in een video van één minuut: https://youtu.be/Y8mD1wLwpWg
Liever lezen? Er is een best practice waarin twee instellingen vertellen hoe ze dit hebben ingezet
Het is mogelijk op de eigen identity provider (IdP), bijvoorbeeld ADFS of Azure AD, Multi-Factorauthenticatie in te richten. Met policy's kan bepaald worden voor welke diensten (SP's) deze MFA vereist is. Normaal gesproken wordt heel SURFconext door de identity provider als één koppeling gezien. Als het niet wenselijk is om MFA te vereisen voor alles achter SURFconext, kan met deze functionaliteit bepaald worden dat MFA alleen nodig is voor specifieke diensten achter SURFconext.
SURFconext kan voor een door de instelling bepaalde set SP's een signaal naar de IdP sturen dat MFA vereist is voor deze SP. Zo kan de IdP vervolgens aan de gebruiker zijn of haar 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 (Azure MFA), maar ook hebben we implementaties met NetIQ en met Vasco tokens bijvoorbeeld.
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 zijn of haar thuisinstelling.
SURFconext heeft voor de IdP een lijst met SP's waarbij die IdP graag MFA wil toepassen. Indien de SP voorkomt in de lijst van de gekozen IdP, stuurt SURFconext in het AuthnRequest naar de IdP een speciale waarde mee in het SAML-element "RequestedAuthnContext". De IdP weet dat er nu dan om MFA gevraagd moet gaan 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 (dit regelt de instelling zelf). Hij stuurt een assertion terug naar SURFconext met de attributen van de gebruiker, en, indien succesvol, dezelfde waarde die in RequestedAuthnContext stond in het element AuthnContextClassRef. Of, specifiek in het geval van ADFS als IdP, in een speciaal extra attribuut (http://schemas.microsoft.com/claims/authnmethodsreferences). SURFconext controleert dat element (of attribuut) om te checken dat de sterke authenticatie inderdaad heeft plaatsgevonden. Indien ja, gaat de gebruiker gewoon verder naar de SP. Indien nee, dan krijgt hij of zij de foutmelding rechts en kan niet verder.
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/Azure MFA, NetIQ of anderszins) geconfigureerd heeft, en gebruikers moeten tokens geactiveerd hebben. We gaan er vanuit dat dit al operationeel is.
Alleen in het geval van Microsoft MFA in combinatie met ADFS moet de IdP het attribuut "http://schemas.microsoft.com/claims/authnmethodsreferences" gaan vrijgeven richting SURFconext. Hiervoor hebben we een handleiding: Toevoegen attribuut AuthnMethodsReferences aan ADFS.
Voor Azure AD IdP's hoeft er geen extra attribuut vrijgegeven te worden, voor IdP's van andere vendors in principe ook niet.
MFA vereisen voor diensten
Als aan de basisvoorwaarden voldaan is, kan de instelling aan SURFconext aangeven voor welke diensten ze MFA wil vereisen. Dit doet de SURFconext-verantwoordelijke via het 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.