This is a list of our most frequently asked questions. For more information about SURFconext Strong Authentication, please visit the relevant pages on this wiki of contact our supportteam.
Dit zijn de meest gestelde vragen. Voor meer informatie kun je terecht op de wiki of bij het supporteam.
How can an application enforce a required level of assurance
The application (or Service Provider in SAML terminology) requests the required Level of Assurance (LoA) via its authentication request to the Strong Authentication gateway.
Voor het doorgeven wordt het gegevensveld "AuthnContextClassRef
" uit de SAML 2.0 standaard gebruikt. Hoe dat precies werkt staat beschreven in "Requesting authentication at a specific LoA". Hiemee is het voor de applicatie mogelijk per authenticatie verzoek de gewenste LoA te bepalen. Zo kan bijvoorbeeld afhankelijk van de gebruiker, of afhankelijk van de in de applicatie gekozen actie om een authenticatie met een hogere LoA worden gevraagd.
In veel gevallen zal de applicatie moeten worden aangepast om dit mogelijk te maken. Daarom willen we het ook mogelijk maken om voor iedere combinatie van applicatie (Service Provider) en instelling (Identity Povider) een minimale LoA af te dwingen op de Sterke Authenticatie gateway. De minimum LoA wordt geconfigureerd op de Sterke Authenticatie gateway. De applicatie hoeft dan geen LoA op te geven. Gevolg is wel dat alle autehnticatie van een instelling naar een applicatie op het minimale niveau plaatsvindt.
Hoe gaat authenticatie als een applicatie sterke authenticatie wilt implementeren?
Step-up authenticatie wil zeggen dat een gebruiker na ingelogd te zijn op een applicatie met een lagere LoA, de LoA van de authenticatie verhoogt. Een applicatie die gebruik maakt van SURFconext Sterke Authenticatie vraagt niet altijd direct om step-up (maar dat kan wel). In plaats daarvan vraagt de Applicatie op een gewenste plek (bijv. admin functionaliteit) om een authenticatie met de door de applicatie vereiste LoA. Een voorbeeld:
- Een gebruiker logt in op een Applicatie. De applicatie vraagt de Sterke Authenticatie gateway om een authenticatie met LoA level 1, het laagste niveau.
- De Sterke Authenticatie gateway vertaalt dit verzoek in een authenticatie, via SURFconext, naar de IdP van de instelling waar de gebruiker authenticeert.
- De Sterke Authenticatie gateway stuurt het resultaat van de authenticatie terug naar de Applicatie.
- De gebruiker wil een actie uitvoeren in de Applicatie waarvoor sterkere authenticatie vereist is.
- De applicatie vraagt de de Sterke Authenticatie gateway om een authenticatie met LoA level 2.
- De Sterke Authenticatie gateway vertaalt dit verzoek in een authenticatie, via SURFconext, naar de IdP van de instelling waar de gebruiker, waarschijnlijk via SSO, geauthenticeerd wordt.
- Omdat voor LoA 2 een tweede factor nodig is, zal de Sterke Authenticatie gateway de gebruiker vragen te authenticeren met zijn tweede factor.
- De Sterke Authenticatie gateway stuurt het resultaat van de authenticatie terug naar de Applicatie.
Moet mijn applicatie in de cloud staan om van SURFconext Sterke Authenticatie gebruik te kunnen maken?
Om gebruik te kunnen maken van SURFconext Sterke Authenticatie moet een applicatie voldoen aan dezelfde eisen als een applicatie die gebruik wil maken van SURFconext. De belangrijkste technische eis is dat de applicatie voor authenticatie gebruik maakt van de SAML 2.0 standaard volgens het Web-SSO profiel. Zie: "Connecting a service to the SURFconext Strong Authentication gateway".
Een instelling mag eigen applicaties aanbieden op SURFconext en Sterke Authenticatie. Zie ook de SURFconext documentatie over het aansluitproces voor diensten van instellingen.
Als een instelling in de eigen IdP sterke authenticatie implementeert, kan die LoA dan doorgegeven worden naar SURFconext Sterke Authenticatie?
Nee. De mogelijkheid om vanuit de instellings IdP een hoger LoA door te geven, en dus geen gebruik te maken van step-up op de SURFconext Sterke Authenticatie gateway willen we (voorlopig) niet aan gaan bieden. Wat SURFconext Sterke Authenticatie biedt is authenticatie op LoA niveau 2 en 3. Hiervoor is zowel sterke authenticatie als sterke identificatie nodig, waarbij de identiteit van de gebruiker sterk verbonden wordt met het authenticatiemiddel. Deze sterke binding en identificatie vereist, naast technische ondersteuning, vooral ook werk op het gebied van organisatie en procedure. Met SURFconext Sterke Authenticatie hebben we voor een opzet gekozen waarmee dit zoveel mogelijk as a service aan de instelling kan worden aangeboden. In deze opzet levert de instellings IdP alleen authenticatie op LoA 1 niveau, de hogere LoA's worden gefaciliteerd door SURFconext Sterke Authenticatie. De management van de benodigde sterke authenticatiemiddelen en het registratieproces vinden plaats via SURFconext Sterke Authenticatie. Door deze opzet kunnen we sterke authenticatie bieden op dezelfde LoA niveau's vanuit verschillende instellingen:
- Zonder aanpassingen aan de technische infrastructuur van de instelling
- Zonder extra audit's van en eisen aan bestaande identiy management systemen en procedures van de instelling
Can an institution re-use its own strong authentication tokens
No. Not it if these are tokens from other vendors of authentication solutions like Vasco, Safenet etc.
The first release of SURFconext Strong Authentication will only support Yubikey hardware tokens (URL wijzigen!) and soft tokens Tiqr (app for iOS or Android) and SMS. Re-use of YubiKey tokens that are already used for is mogelijk. Omdat voor authenticatie gebruik gemaakt wordt van de Yubico authenticatie servers moeten de tokens voorzien zijn van de daarvoor benodigde configuratie. Yubikey tokens worden standaard geleverd in een configuratie die geschikt is voor gebruik met SURFconext Sterke Authenticatie.
SURFconext Strong Authentication is designed as such that it is possible of other authentication tokens in the future.
iets toevoegen over security risico: secret wordt op 2 plaatsen gedeeld
In geen geval kan een bestaande registratie, bijvoorbeeld wie heeft welk token in bezit, worden hergebruikt.
Ook hergebruik van tokens van andere leveranciers zoals bijv. Vasco, Safenet is niet mogelijk.
Why is the activation code designed as it is
The activation code should have enough entropy to prevent a guessing attack (an attacker should not be obtain the valid code via trial-and-error by generating codes), yet short enough to be written down by the user.