De huidige SURFsecureID configuratie is voor een SURFsecureID RAA van een instelling in te zien in het Instellingconfiguratie scherm in de RA. Een wijziging kun je aanvragen via support@surfconext.nl.

Op deze pagina leggen we uit wat de verschillende configuratie opties betekenen. We houden dezelfde volgorde aan als in het Instellingconfiguratie scherm.

Gebruik RA-locaties ingeschakeld? en Laat RAA contact informatie zien?

Voor instellingen zijn er twee mogelijkheden om aan te geven waar gebruikers hun tokens moeten activeren:

1. RA-locaties ingeschakeld: de RA(A) kan verschillende locaties configureren met naam, locatie en contactgegevens die worden getoond aan de gebruikers.
2. RA-contactpersonen (RA-locaties niet ingeschakeld): de persoonlijke contactgegevens van individuele RA(A)'s wordt getoond aan de gebruikers. In dit geval is er nog de optie of de contactgegevens van de RA-admin (RAA) wel/niet getoond moet worden ("Laat RAA contact informatie zien?")

Standaard staat RA-contactpersonen aan voor nieuwe instellingen.

"Laat RAA contact informatie zien" heeft alleen effect als Gebruik RA-locaties is uitgeschakeld.

Meer informatie over RA locaties beheren.

E-mail verificatie ingeschakeld?

Standaard moet de gebruiker tijdens het registreren van een token zijn e-mailadres verifiëren. Het e-mailadres wordt gebruikt om de gebruiker in te lichten over mutaties aan zijn tokens. Maar, als de email voorziening van een instelling beveiligd wordt met SURFsecureID is het voor de gebruiker niet mogelijk zijn e-mailadres te bevestigen. In dit geval kan de e-mailverificatie uitgezet worden. Ook kan het zijn dat de instelling zeker weet dat het e-mailadres van de gebruiker klopt waardoor deze stap niet nodig is.

Zie ook de Handleiding Registratieportal.

Single sign on op second factor token authenticaties?

SURFsecureID bied de mogelijkheid tot Single-Sign-on op de tweede factor authenticatie. Deze SSO werkt met een persistent cookie in de browser en verloopt na 10 uur.

Staat single-sign-on (SSO) uit, dan vindt er nooit SSO plaats op de twee factor authenticatie in SURFsecureID. Authenticaties naar AzureMFA kunnen, afhankelijk van de configuratie in Azure wel SSO hebben. Omdat deze SSO buiten SURFsecureID plaatsvindt heeft SURFsecureID geen invloed op het SSO gedrag.

Als SSO aanstaat in de configuratie voor een instelling, dan bepaald de configuratie van de service provider in SURFconext of de configuratie van de SFO koppeling of er SSO plaats vind. Er vindt dus alleen SSO plaats als SSO aanstaat op zowel de service provider koppeling in SURFconext (default aan) en de configuratie voor de instelling in SURFSecureID.

Ons advies is om SSO zo veel mogelijk aan te zetten, en alleen voor specifieke use-cases uit te schakelen. Bijvoorbeeld wanneer de twee-factor authenticatie gebruikt wordt om een specifieke actie te authoriseren zoals bijvoorbeeld bij het accorderen van cijfers van studenten/leerlingen.

Toegestane tokens

De instelling kan kiezen welke token types er ondersteund moeten worden. Op dit moment zijn er 5 tokentypes, namelijk tiqr, SMS, AzureMFA, Yubikey en FIDO2 waarbij we adviseren SMS niet meer te gebruiken (zie de overwegingen over SMS als token). Een instelling moet minimaal één van de LoA3 tokens (Yubikey of FIDO2) ondersteunen omdat deze nodig zijn voor de toegang tot het RA portaal.

De toegestane tokens opties bepaald welke tokens toegestaan zijn voor nieuwe token registraties door een gebruiker, het heeft geen invloed op de reeds geactiveerde tokens. Gebruik het tokens overzicht in het RA portal om te zien welke token types er actief zijn.

Meer informatie over SURFsecureID gebruiken.

Aantal tokens per identiteit

De instelling kan kiezen hoeveel tokens een gebruiker maximaal actief mag hebben. Dit moeten altijd wel tokens van verschillende types zijn. Als deze waarde op 2 staat kan een gebruiker bijvoorbeeld een FIDO2 en een tiqr token hebben, niet 2 tiqr tokens. Een waarde van >1 is nodig om de optie "Bestaand token gebruiken om te activeren" te kunnen gebruiken.

Van welke instelling(en) kunnen de gebruikers de RA(A) rol krijgen voor deze instelling?

Dit geeft de lijst met instellingen waarvoor individuele gebruikers een RA of RAA rol toegekend kunnen krijgen in deze instelling. Standaard zijn dit alleen gebruikers van de eigen instelling. Deze optie kan leeg zijn, er kunnen geen nieuwe individuele RA of RAA rollen worden toegekend. Deze optie kan ook meerdere instellingen bevatten. Deze optie heeft geen invloed op reeds bestaande RA en RAA rollen.

Meer informatie over RA-rollen toewijzen.

Van welke instelling(en) zijn de RA's een RA voor deze instelling?

Dit geeft de lijst met instellingen waarvan de gebruikers met een RA rol in die instelling ook RA rechten hebben in deze instelling. Standaard staat hier alleen de eigen instelling. Deze optie kan leeg zijn, er zijn dan effectief geen gebruikers met RA rechten in de instelling.

Meer informatie over RA-rollen toewijzen.

Van welke instelling(en) zijn de RAA's een RAA voor deze instelling?

Dit geeft de lijst met instellingen waarvan de gebruikers met een RAA rol in die instelling ook RAA rechten hebben in deze instelling. Standaard staat hier alleen de eigen instelling. Deze optie kan leeg zijn, er zijn dan effectief geen gebruikers met RAA rechten in de instelling.

Meer informatie over RA-rollen toewijzen.

Bestaand token gebruiken om te activeren

Als deze optie aan staat kan een gebruiker die al een ander token heeft hiermee een nieuwe token te activeren. Voorwaarde is dat het bestaande token waarmee geactiveerd wordt van voldoende niveau is; een LoA groter of gelijk aan het nieuwe token. Zo kan een FIDO2 token wel met een Yubikey geactiveerd worden, maar niet met een tiqr token. Deze activatie methode is optioneel en moet voor een instelling aan staan. Voorwaarde om deze optie in praktijk te kunnen gebruiken is dat de instelling meerdere tokens per gebruiker op twee of hoger heeft staan.

Meer informatie over het Registratie- en activatieproces

Token activeren zonder servicedesk of bestaand token

Als deze optie aan staat kan de gebruiker zijn token zelf activeren zonder dat deze via een servicedesk geactiveerd moet worden. De gebruiker moet dan een herstelmethode instellen om ervoor te zorgen dat bij verlies van het token er toch nog een nieuw token geactiveerd kan worden. De gebruiker kiest daarvoor tussen SMS en herstelcode. Na het configureren van de herstelmethode is het token geactiveerd en klaar voor gebruik als LoA 1.5 token. 

Als de instelling de zelf activatie methode aangezet heeft blijft de servicedesk activatie methode beschikbaar voor de instelling. Een gebruiker moet dan dus zelf kiezen welke methode hij gebruikt, wat soms lastig of ongewenst is. Daarom heeft de instelling de optie om de gebruiker te dwingen een bepaalde activatiemethode te kiezen, of de gebruiker voor te lichten over welke methode hij het beste kan kiezen. Zie Registratie- en activatieproces.

Meer informatie over het Registratie- en activatieproces