...
- In addition to an existing institutional login. SURFsecureID is only used for the 2nd factor. This is especially interesting for use by a central (authentication) facility such as ADFS, Citrix or F5 BIGIP. This facility handles the 1st factor itself and calls SURFsecureID for the 2nd factor if necessary. This makes strong authentication available for a range of internal and external (cloud) services. This option is also called Second Factor Only, especially in the more technical documentation.
- For a (cloud) service. The service outsources the complete login (ie both the 1st and the 2nd factor) to SURFconext. The 1st factor (username / password) via the IdP and the 2nd factor via the available SURFsecureID tokens.
The service (Service Provider, or SP) is connected to SURFconext which is configured to call SURFsecureID for this service. This makes it especially easy for services already connected to SURFconext to use SURFsecureID as this is transparant for the service. The service can use either SAML or OpenID Connect to connect to SURFconext. You can make use of step-up policies in SURFconext to only request SURFsecureID for specific users (attribute based) or locations (IP adres based). Also, the service can request a specific LoA level in the request to SURFconext (NB: before june 2021, this was only possible when the service was connected to SURFsecureID directly).
When you use the SURFsecureID pilot environment, the service needs to connect to SURFsecureID instead of SURFconext.
SURFsecureID gives access to services via five different types of tokens: SMS, Tiqr (smartphone app), Azure MFA, YubiKey (USB hardware token) or FIDO2 token. An institution can choose which tokens they want to allow for their users. Users first log in with their institutional account and are then prompted to confirm their identity with their token. In this way there is a second layer of security.
...