Frequently Asked Questions

Yes. In order to connect to SURFconext Strong Authentication, an application must meet the same requirement as when connecting to SURFconext. The main technical prerequisite is that a Service Provider must connect via SAML2.0 WebSSO. For more info: "Connecting a service to the SURFconext Strong Authentication gateway".

Yes. Every institution that is already connected to SURFconext, can connect its own services to the SURFconext Strong Authentication gateway. For more info: SURFconext documentation on how to connect institutional services.

The application (or Service Provider in SAML terminology) requests the required Level of Assurance (LoA) via its authentication request to the Strong Authentication gateway.

To communicate the required Level of Assurance we use the "AuthnContextClassRef" from SAML 2.0.  Our wiki "Requesting authentication at a specific LoA" describes how this will work. This enables the application to define the required Level of Assurance for each authentication request. The required Level of Assurance can be triggered because a certain user authenticates, or a certain feature in the application is selected. In most cases modifications to the application will be required to facilitate this.

We will also support Level of Assurance enforcement on the gateway to enable an institution to enforce a minimum LoA for a certain Service Provider. The minimum LoA will  be configured on the Strong Authentication gateway. No modifications to the application are necessary. A a consequence authentication for all users from one institution to one application will always require the minimum LoA.

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.

For security reasons SURFconext Strong Authentication does not support SSO:

• Every authentication request from an SP will be redirected to SURFconext. SURFconext will redirect the request to the IdP. The IdP will offer Single Sign On most of the times.
• For every authentication request from an SP with a LoA > 1 (which is every step-up request) will require a new authetication from the user with his/ her token.

SURFconext Strong Authentication does not support Single Sign On (SSO). As a result there is no active session on the Strong Authentication gateway for a user to logout. For first factor login SURFconext Strong Authentication relies on SURFconext. Therefore, the same issues for (single) logout apply. For more info read:

• Blog "Damn you, single log out"
• Factsheet

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

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.

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.