Yes. The main technical prerequisite is that a Service Provider must connect via SAML 2.0 using the Web Browser SSO profile.
Yes. Every institution connected to SURFconext as an Identity Provider can connect its services to SURFsecureID.
This is done via the authentication request to the SURFsecureID gateway. Enforcing a specific level of assurance can be done in two ways:
Remote registration is vulnerable to threats and technically complex to achieve. In person registration is therefore the most efficient option. In Q4 of 2017, Innovalor reviewed the options for remote registration. This has resulted in a design an POC phase in the first half of 2019.
Google offers second factor authentication in the form of an SMS service and a smart phone OTP app, but has no face-to-face registration processes. For an individual Google user this will be fine. But for an educational institute, protecting its organisational assets and its reputation, a self-asserted second factor is not enough. They want to determine that a service provider (e.g. a student information system) is dealing with a legitimate user. Face-to-face registration is inevitable to achieve this.
Yes, SURFsecureID supports single-sign on (SSO) on the second factor. If enabled, the user will only need to login once a day (per device) with his second factor. The institution needs to enable this feature for all logins and can disable it for specific services. See also Configuratie opties#SingleSign-On(SSO)
Note that SURFsecureID does not always control SSO for the second factor. When using the Second Factor Only functionality, the central facility (like ADFS) controls SSO.
SURFsecureID does not support Single Sign On (SSO). As a result there is no active session on the SURFsecureID gateway for a user to logout. For first factor login SURFsecureID relies on SURFconext. Therefore, the same issues apply as with SURFconext.
No. SURFsecureID does not support the transfer of levels of assurance via the local IdP.
LoA 2 and LoA 3 authentication requires (1) strong authentication, (2) strong identification and (3) a solid binding between the user identity and his token. Local implementations of strong authentication (at the IdP) do not guarantee the same solid binding between the user identity and his token. This means that SURFconext cannot guarantee that such an IdP-specific LoA2 and LoA3 implementation is equal to LoA2 and LoA3 facilitated by SURFsecureID. Therefore this is not supported.
Yes, this is possible with AzureMFA tokens or FIDO2 tokens. It is also possible to re-use Yubikey tokens, however using a Yubikey many places increases the risk of fishing attacks.
The activation code should have enough entropy to prevent a guessing attack and yet short enough to be written down by the user.
14 days after registering a token. To get a new activation code a user must delete the registered token and start a new registration.
Threat | Description | Controls |
---|---|---|
Impersonation | An applicant claims an incorrect identity, supporting the claim with a specific set of attributes created over time or by presenting false credentials. | During the registration process different methods are used to determine that the applicant is the right person:
|
Compromise or malfeasance of the infrastructure | Lack or poor implementation of security measures undermine the reliability of the registration. | Infrastructure threats are addressed by normal computer security controls:
Also a third party security audit on software code and infrastructure was conducted. |
There are several options where you can buy YubiKeys.
Yes. If the user's institution allows the use of multiple tokens, the user can register multiple tokens as long as each one is of a different type. For example, a user can register a tiqr and a Yubikey, but not two tiqr apps or two Yubikeys.
No. For security reasons only one token registration per user is allowed.
The length of the session is SP specific. For usability reasons it should not be too short (< 30 min), for security reasons it should not be too long (> 4-8 hours).
No. Our policy - in line with ISO29115 - explicitly requires a user to appear in person.
There are two ways to achieve this: