Er zijn verschillende SURFsecureID configuratie opties voor een instelling. Een wijziging in deze opties kun je aanvragen via support@surfconext.nl.
Token types
De instelling kan kiezen welke token types er ondersteund moeten worden. Op dit moment zijn er 5 token types, 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.
Aantal tokens per gebruiker
De instelling kan kiezen hoeveel tokens een gebruiker mag hebben. Dit moeten 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 voor de optie "token activatie met een bestaand token" (zie hieronder).
Zelf activatie
Als deze optie aan staat kan de gebruiker zijn token zelf activeren. 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#Gebruikersturennaareenactivatiemethode.
Single Sign-On (SSO)
Met deze optie hoeft een gebruiker nog maar 1x per dag (per device) met zijn SURFsecureID 2e factor in te loggen. SSO wordt geconfigureerd per instelling en staat voor nieuwe SURFsecureID afnemers standaard aan. SSO staat dus voor een hele instelling aan of uit. Indien SSO voor een instelling aan staat kan SSO voor specifieke applicaties uitgezet worden. Als jouw instelling SSO wil aan- of uitzetten, of SSO voor een applicatie wil uitzetten, neem dan contact op met support@surfconext.nl.
Token activatie een bestaand token
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 is wel dat de instelling meerdere tokens per gebruiker aan heeft staan, of dit tegelijk aan laat zetten.
Externe RA's of RAA's
Standaard is het zo dat alleen gebruikers van de eigen instelling de RA of RAA rol kunnen vervullen. Het is echter ook mogelijk om een RA of RAA rol toe te kennen aan gebruikers van andere instellingen. Deze "externe" RA's of RAA's krijgen precies dezelfde rechten als de RA's en RAA's van de eigen instelling. In SURFsecureID kan per instelling geconfigureerd worden van welke andere instelling(en) gebruikers een RA of RAA rol kunnen krijgen.
Email verificatie
Standaard moet de gebruiker tijdens het registreren van een token zijn email adres verifiëren. Het email adres 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 email adres te bevestigen. In dit geval kan de email verificatie uitgezet worden. Ook kan het zijn dat de instelling zeker weet dat het email adres van de gebruiker klopt waardoor deze stap niet nodig is.
RA locaties
Voor instellingen zijn er twee mogelijkheden om aan te geven waar gebruikers hun tokens moeten activeren:
- RA-locaties: de RA(A) kan verschillende locaties configureren met naam, locatie en contactgegevens die worden getoond aan de gebruikers.
- RA-contactpersonen: 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.
Standaard staat RA-contactpersonen aan voor nieuwe instellingen.