FAQ

Kun je zelf als instelling kiezen welke methode wordt gebruikt? Of kiest de eindgebruiker dat zelf?

Dit wordt waarschijnlijk een getrapt model. De instelling kiest welke tokens beschikbaar zijn: SMS, Tiqr en/ of Yubikey. Vervolgens kan gebruiker uit de beschikbare tokens kiezen. Als instelling alleen Tiqr ondersteunt, dan valt er weinig te kiezen. We denken nog na over hoe je dat keuzeproces verder kan stroomlijnen, ook gezien de financiële consequenties van SMS (ca 6-8 cent/ transactie) en Yubikey (20-25 euro eenmalige aanschafwaarde). Mogelijkheden:

• We willen het mogelijk maken via een directe link (in bijvoorbeeld een mail van de instelling) een gebruiker direct voor een type token te laten kiezen.
• Nadat een gebruiker de self service registratie heeft afgerond volgt er nog een contactmoment met de instelling, namelijk de vetting door een RA. Dit geeft de instelling nog controle (achteraf) op de gekozen tokens

Moet je je 2e factor binnen één browsersessie meerdere keren gebruiken of blijft dat per browsersessie gelden?

Besloten is om geen SSO aan te bieden op de sterke authenticatie gateway. Dit betekent dat:

• Ieder authenticatie verzoek van een SP altijd wordt doorgeleid naar SURFconext, en vanaf daar naar de instellings IdP. De Instellings IdP zal typish SSO aanbieden.
• Voor ieder authenticatie verzoek van een SP voor een LoA > 1 (dus ieder step-up verzoek) de gebruiker gevraagd wordt voor authenticatie met zijn/ haar tweede factor.

Hoe verloopt de enrollment van gebruikers?

Voordat een gebruiker gebruik kan maken van sterke authenticatie via SURFconext Sterke Authenticatie moet hij voorzien worden van een sterk authenticatie middel. Dit proces wordt ook wel "enrollment" genoemd. Enrollment gaat via de self-service Registratieportal van SURFconext Sterke Authenticatie. Het eerste gedeelte van dit proces is self-service. De gebruiker logt met zijn instellingsaccount (1e factor) in op de Registratieportal, en vraagt vervolgens één van de ondersteunde authenticatiemiddelen (SMS, Tiqr, YubiKey) in voor zijn account.

Om zijn authenticatiemiddel te laten activeren moet de gebruiker langs bij een RA (=Registration Authority, doorgaans een Service Desk of IT Helpdesk). Een daartoe geauthoriseerde medewerker (RA) zal na een succesvolle controle ophet bezit van het aangevraagde authenticatiemiddel en de identiteit van de gebruiker, het authenticatiemiddel van de gebruiker activeren.

Dit enrollementproces doorloopt de gebruiker eenmalig. Het is dus niet specifiek voor een enkele SP. Na het doorlopen van het enrollment proces kan de gebruiker de sterke authenticatie gebruiken met alle SPs die aan SURFconext Sterke Authenticatie zijn gekoppeld.

In principe kan iedere gebruiker van een instelling die gebruik maakt van SURFconext Sterke Authenticatie zichzelf enrollen via de enrollment website. In de praktijk verwachten we dat dit zal gaan met bijvoorbeeld een uitnodiging die aan de gebruiker verstuurd wordt door de instelling, of met een verwijzing vanuit een SP.

Hoe werkt single logout in combinatie met SURFconext Sterke Authenticatie?

Omdat er geen SSO plaats vindt op de Sterke Authenticatie gateway, is er ook geen sessie op de Sterke Authenticatie gateway waarop uitgelogd moet worden. Voor de 1e factor login maakt SURFconext Sterke Authenticatie gebruik van de functionaliteit van SURFconext. Voor (single)logout gelden dezelfde (on)mogelijkheiden als voor SURFconext. Zie ook:

• De blog "Damn you, single log out": https://blog.surfnet.nl/?p=2570
• En de factsheet: http://www.surf.nl/kennis-en-innovatie/kennisbank/2014/factsheet-making-log-out-work-for-a-single-service-on-surfconext.html

Hoe geeft de applicatie het gewenste LoA door aan SURFsure?

De applicatie (de Service Provider in SAML terminologie) geeft het gewenste Level of Assurance (LoA) niveau door in het authenticatieverzoek naar de Sterke Authenticatie 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:

1. Een gebruiker logt in op een Applicatie. De applicatie vraagt de Sterke Authenticatie gateway om een authenticatie met LoA level 1, het laagste niveau.
2. De Sterke Authenticatie gateway vertaalt dit verzoek in een authenticatie, via SURFconext, naar de IdP van de instelling waar de gebruiker authenticeert.
3. De Sterke Authenticatie gateway stuurt het resultaat van de authenticatie terug naar de Applicatie.
4. De gebruiker wil een actie uitvoeren in de Applicatie waarvoor sterkere authenticatie vereist is.
5. De applicatie vraagt de de Sterke Authenticatie gateway om een authenticatie met LoA level 2.
6. 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.
7. Omdat voor LoA 2 een tweede factor nodig is, zal de Sterke Authenticatie gateway de gebruiker vragen te authenticeren met zijn tweede factor.
8. 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

Kan ik mijn bestaande sterke authenticatie middelen hergebruiken?

In de eerste versie van SURFconext Sterke Authenticatie zullen alleen Yubikey hardware tokens worden ondersteund. Daarnaast wordt als soft token Tiqr ondersteund en is er ondersteuning van SMS authenticatie. SURFconext Sterke Authenticatie wordt zo ontworpen dat het goed mogelijk is nieuwe soorten authenticatie middelen toe te voegen.

Hergebruik van bestaande Yubikey tokens 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.

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.