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 SAML 2.0 using the Web Browser SSO profile. For more info: "Connecting a service to the SURFconext Strong Authentication gateway".

Yes. Every institution that is already connected to SURFconext as an Identity Provider, can connect its own services to the SURFconext Strong Authentication gateway. For more info: SURFconext documentation on how to connect institutional services or read our more specific documentation on how to connect services to SURFconext Strong Authentication

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 works. This enables the application to define the required Level of Assurance for each authentication request. The required Level of Assurance can be determined by the application based on the user that authenticates, or the feature in the application that selected. In most cases modifications to the application will be required to facilitate this.

The SURFconext Strong Authentication gateway also supports static configuration of a minimum LoA on the gateway based on the IdP and SP involved in the authentication. This enables an institution to enforce a minimum LoA for a certain Service Provider. The minimum LoA will be configured on the Strong Authentication gateway so the application does not have to be modified to specify the LoA during authentication. As a consequence authentication for all users from one institution to one application will then always require the same 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 reasons of simplicity, transparency and security SURFconext Strong Authentication does not support SSO. This means that:

• Every authentication request from an SP will be redirected to SURFconext. SURFconext will redirect the request to the user's home IdP. This IdP will offer Single Sign On most of the times.
• Every authentication request from an SP with a LoA > 1 (which is every step-up request) will require a new authentication with the user's 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. SURFconext Strong Authentication will not support the transfer of LoAs via the local IdP for a reason:

SURFconext Strong Authentication offers LoA 2 and LoA 3 authentication. This requires both strong authentication and strong identification, and a solid binding between the identity of the user and its authentication token. This solid binding and identification requires technical measures, but also organizational and procedural measures. SURFconext Strong Authentication is designed to offer this as-a-service to every institution. This set-up allows the institutional IdP to facilitate LoA1 authentication, while LoA2 and LoA3 authentication is facilitated by SURFconext Strong Authentication.

The required authentication tokens and the registration process are managed centrally by SURFconext Strong Authentication. This generic set-up, that is equal for all participating institutions, allows us to offer strong authentication based on Level of Assurance from different institutions:

• Without modifications to the technical infrastructure of the institution.
• Without extra audit requirements for existing identity management systems and procedures at the institution.

Local implementations of strong application at the IDP do not guarantee the same solid binding between the identity of the user and its authentication token. SURFconext Strong Authentication cannot guarantee to SPs that such a IdP-specific LoA2 and LoA3 implementation is equal to LoA2 and LoA3 facilitated by SURFconext Strong Authentication. Therefor this is not supported.

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. Subject to certain conditions YubiKey tokens that are already used internally can be re-used. Since SURFconext Strong Authentication utilizes Yubico authentication servers these token need the appropriate configuration. Yubikey Edge, Neo and Standard tokens are by default suited to use with SURFconext Strong Authentication

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.

The registration process is designed, to a greater or lesser degree depending on the assurance level, to ensure that the registration authority (RA) knows the true identity of the applicant. SURFconext Strong Authentication has implemented different controls in both its architecture as its infrastructure to mitigate possible threats: