Table of Contents |
---|
Should my application be web based to connect to
...
SURFsecureID?
Yes. The main technical prerequisite is that a Service Provider must connect via SAML 2.0 using the Web Browser SSO profile.
Can institutions from secondary vocational-, higher education and research connect their own services to
...
SURFsecureID?
Yes. Every institution connected to SURFconext as an Identity Provider can connect its services to SURFconext Strong AuthenticationSURFsecureID.
How can an application enforce a specific level of assurance?
This is done via the authentication request to the SURFconext Strong Authentication SURFsecureID gateway. Enforcing a specific level of assurance can be done in two ways:
- Dynamically by communicating the required level of assurance with "AuthnContextClassRef". In this way the required level can be defined for each authentication request individually (based on the user authenticating or the selected feature in the application). In most cases modifications to the application are required to facilitate this.
- Statically: in the SURFconext Strong Authentication gateway SURFconext a minimum level of assurance can be configured (based on the IdP and SP involved). In this way the application does not have to be modified. Authentication for all users from one institution to one application will always require the same minimum level of assurance.
- Based on user context: with SURFconext step-up policies, a rule can be made based on the user's context (user attributes, IP address) that will require a specific SURFsecureID LoA.
Why is remote registration not supported?
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. It is expected that we will try some of these options in a pilot settingThis has resulted in a design an POC phase in the first half of 2019.
Why is Google Authenticator not supported?
...
Can a second factor authentication be re-used in one browser session?
No. For reasons of simplicity, transparency and security SURFconext Strong Authentication does not support Single Sign On Yes, SURFsecureID supports single-sign on (SSO) on the second factor. This means that every authentication request from an SP with a LoA > 1 (every step-up request) requires a new authentication with the user's token.
SSO on the first factor is enabled!
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.
How does single logout work with
...
SURFsecureID?
SURFconext Strong Authentication SURFsecureID does not support Single Sign On (SSO). As a result there is no active session on the SURFconext Strong Authentication SURFsecureID gateway for a user to logout. For first factor login SURFconext Strong Authentication SURFsecureID relies on SURFconext. Therefore, the same issues for single logout applyapply as with SURFconext.
Can an institution implement strong authentication on their own IdP and
...
then forward the level of assurance to
...
SURFsecureID?
No. SURFconext Strong Authentication 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 SURFconext Strong AuthenticationSURFsecureID. Therefore this is not supported.
Can an institution re-use its own strong authentication tokens?
No, SURFconext Strong Authentication supports only Yubikey hardware tokens, Tiqr and SMS. Other tokens like the ones from Vasco and Safenet cannot be re-used at the moment. However, SURFconext Strong Authentication has succesfully carried out a proof-of-concept with Vasco to use their tokens with SURFconext Strong Authentication. Depending on user demand SURFconext could enable this optionYes, 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.
Why is the activation code designed as it is?
...
14 days after registering a token. To get a new activation code a user must delete the registered token and start a new registration.
How can
...
SURFsecureID ensure that tokens are bound to the right identity?
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. |
How can I order YubiKey tokens?
Yubikeyshop.nl offers a special discount for institutions in Dutch secondary vocational-, higher education and research, but you can also buy them at another vendor. There are several options where you can buy YubiKeys.
Can a user register multiple tokens?
No. For security reasons only one token registration per user is allowed. The functionality to register more token types for one user is currently on the roadmapYes. 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.
Can I install the Tiqr app on multiple devices after registering once?
...
How can I revoke the token of a user?
There are three two ways to achieve this:
- The easiest way is to remove the first factor of the user (= username/password) through your regular exit proces/ IDM-lifecycle. Once the first factor is removed, the user can no longer use his second factor.
- Ask the RA of your institution to remove the second factor registration through the RA Management portal.
- Users who have not used their token for 6 months receive a reminder by e-mail. If they do not react, SURFconext will remove their token registrations.
...