Frequently Asked Questions

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.

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.

Different registration processes and mechanisms applied to identity vetting, proofing and credentialing result in different registration assurance levels. An applicant may appear in person to register, or the applicant may register remotely.

Remote registration is limited to Levels 1 through 3 and is more vulnerable to threats and technically complex to achieve. Remote registration relies on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number (BSN), and photo. Examples of such sources are the institution’s HR system or the government/municipal administration (in The Netherlands: Basisregistratie Personen, BRP) Consultation of the latter source is restricted by legislation and not available for SURFconext Strong Authentication purposes; the HR system on the other hand could be used as an alternative source. Typically, after a successful validation, a registration activation code is sent to the applicant’s home address. This is cumbersome and expensive.

Therefore, in person registration seems the most efficient option. In case the user is somehow not able to register in person, video conferencing tools such as Skype or Lync could be used. In this case the user identifies him/herself via the video conference and shows his/her passport or other valid photo-ID to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other – less attractive and/or appropriate – alternatives (such as use of physical address, email & mobile phone, use of bank account).

Different circumstances may translate to different requirements. There are use cases in which a second factor authentication token without a strict registration process makes sense: Google, for example, offers second factor authentication to its users in the form of an SMS service and a smart phone OTP app, but has no face-to-face registration processes in place.

The difference between this “Google use case” and the use cases of most institutions is that Google users are protecting their own account (from, say, snooping governments) as opposed to the educational institute’s student information system use case where the IdP is protecting its organisational assets (or its reputation). In the latter case, there is a strong need to be able to determine that a service provider (e.g. a student information system) is dealing with a legitimate user, thus necessitating a stringent identity proofing process during user registration (i.e. a face-to-face process) described below.

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.

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.

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

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.

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

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 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.

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.