Via SURFconext is het mogelijk om MFA op de IdP in te schakelen voor specifieke diensten achter SURFconext. Deze functionaliteit is echter beperkt en de logische richting lijkt omgekeerd: we willen er naar toe dat alle logins op diensten achter SURFconext met (een vorm van) MFA zijn beschermd, en iets doen met de enkele uitzonderingen waarvoor dit niet gewenst is. In dit document geven we een schets van mogelijke oplossingsrichtingen.

Achtergrond van het probleem

Het achterliggende probleem is dat waar eerder nog MFA alleen ingezet werd voor enkele specifieke diensten, we nu zien dat instellingen andersom redeneren. Er wordt beleid gedefinieerd waarbij MFA met bepaalde regelmaat en op bepaalde criteria gevraagd kan worden aan de user, maar wel in principe voor alle applicaties (met soms enkele uitzonderingen). Immers, alhoewel het belang verschilt, is het uiteindelijk bij elke applicatie ongewenst dat een hacker die een gebruikersnaam en wachtwoord in bezit heeft, zich daar toegang toe verschaft.

Het probleem hier is vooral hoe het praktisch in te richten met SURFconext, en dan met name voor Microsoft geleverde IdP-producten. Producten van Microsoft kunnen niet 'zien' welke eind-SP zich achter SURFconext bevindt, en dus niet op basis daarvan hun policies aanpassen. Dit betekent dat SURFconext in zijn geheel als 1 app gezien wordt door Entra ID/ADFS en alleen op die ene app als geheel vervolgens conditional access policy's(bv voor MFA) toegepast kunnen worden.

Om hier toch iets meer mee te kunnen doen heeft SURFconext heeft een functie waarmee SURFconext een seintje kan meesturen bij een loginverzoek aan de IdP dat voor die login MFA vereist is. Dit seintje kan in het IdP dashboard ingeschakeld worden per SP. Daardoor worden voor logins op die SP door SURFconext het betreffende seintje meegestuurd. Wat Microsoft echter toestaat met dit seintje te doen is echter beperkt: Entra ID of ADFS ziet dit seintje als vraag om op dat moment MFA te vragen. En kan het niet koppelen aan zoiets als conditional access-regels. Dit is een beperking van MS, ze bieden verder geen andere functionaliteit voor SURFconext om MFA-wensen te signaleren voor diensten achter SURFconext.

Het is niet goed schaalbaar of wenselijk voor de instelling om in SURFconext voor alle SP's via het IdP dashboard dit vinkje aan te gaan zetten behalve de enkele SP's waarvoor men geen MFA wil. Zeker omdat hierbij ook geen gebruik gemaakt kan worden van bv omgevingsfactoren, zoals mogelijk is in conditional access policies. Vandaar de vraag hoe dan wel om te gaan met MFA en SURFconext.

Oplossingsrichtingen

We adviseren om op SURFconext als geheel een conditional access policy te zetten die een vorm van MFA verplicht stelt voor logins. Met daarin de door de organisatie gewenste mate van SSO, meenemen van condities zoals werkplek etc. Als uitgangspunt is het namelijk altijd wenselijk dat elke dienst achter SURFconext met MFA beschermd wordt.

Vervolgens is het zaak een oplossing te verzinnen voor de uitzonderingen waarbij het vragen van MFA echt ongewenst is. Afhankelijk van de precieze wensen gaat het vermoedelijk slechts om enkele applicaties tussen de meestal tientallen of honderden die via SURFconext in gebruik zijn. Hiervoor zijn op hoofdlijnen twee oplossingsrichtingen denkbaar:

Gebruik andere uitzonderingsgrond dan de applicatie

De eerste mogelijke oplossing is om de gevallen waarin je niet wilt dat gebruikers om MFA gevraagd worden, op een andere manier uit te drukken in de conditional access policy die van toepassing is op de app SURFconext (want de achterliggende applicatie is niet bekend). Men wil bijvoorbeeld geen MFA vereisen omdat dit lastig is bij toetsen waarbij mensen geen telefoon bij zich mogen hebben. In de conditional access policy kies je er dan bijvoorbeeld voor om MFA niet te vereisen als je inlogt vanuit de toetszaal - in plaats van als je inlogt op de toetsapplicatie. Zo kunnen mensen die in de toetszaal zijn zich zonder MFA aanmelden op de toetsapplicatie, ook al zit die wel achter SURFconext. Je gebruikt dus de locatie van de gebruiker als input voor de regel.

Koppel vreemde eenden direct aan de instellings-IdP

Een andere oplossingsrichting is om de enkele uitzonderingen die afwijken van het standaardbeleid niet via SURFconext te ontsluiten maar direct aan Entra/ADFS te hangen. SURFconext gebruik je dan voor de tientallen of honderden applicaties die onder het algemene regime vallen, en zo kan dit regime eenvoudiger en begrijpbaarder gehouden worden voor de bulk van de logins. Voor de ene of enkele vreemde-eend-SP's/uitzonderingen is het prima te billijken om er een aparte Entra ID app-koppeling voor te maken, die van een specifieke policy te voorzien. Weer met hetzelfde voorbeeld koppel je de toetsapplicatie direct aan Entra ID, waarnaar je daar een toets-specifieke conditional access policy voor maakt.

Zet SURFsecureID in

SURFsecureID is de mfa-as-a-serviceoplossing van SURF. Omdat we die zelf ontwikkelen en daarom niet afhankelijk zijn van de beperkingen van bepaalde IdP-software, kan SURFsecureID flexibeler zijn en op basis van verschillende aspecten zoals de betreffende applicatie en attributen van de gebruiker de keus maken wanneer om een tweede factor gevraagd wordt. Zie voor meer informatie: SURFsecureID.