...
| borderColor | #4fb3cf |
|---|---|
| bgColor | #ffffff |
| titleColor | #ffffff |
| titleBGColor | #4fb3cf |
| borderWidth | 2 |
| borderStyle | solid |
...
SURFsecureID gives institutions secure access to
...
services
...
. Better security is particularly critical for
...
services handling
...
sensitive data
...
.
...
Such services require stronger forms of authentication than a username and password in order to limit the risk of
...
security incidents.
The availability of Strong Authentication functionality enables institutions to enforce strong authentication for cloud services linked to SURFconext. SURFconext acts as a link between the institutions and service providers. Institutions can select the services they wish to secure with stronger authentication.
...
Institutions can use SURFsecureID in two ways. Both can be used at the same time:
- 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).
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
...
.
SURFsecureID is available at an additional fee for all institutions connected to SURFconext.
How does
...
token registration work?
...
An institution can either allow their users to perform self-service token registration, or have a servicedesk validate the user's identity before a token can be used. These different processes result in a different level of assurance (LoA) for the registered token.
Self-service token registration:
- The user registers his preferred token (SMS, Tiqr, Azure MFA, Yubikey or FIDO2) in the registration portal
- The user registers a recovery method (SMS or recovery code).
- Now the user can log in to any service with a level of assurance lower or equal to LoA1.5.
Token registration via the institution's servicedesk:
- The user registers his preferred token (SMS, Tiqr, Azure MFA, Yubikey or FIDO2) in the registration portal
- User must visit his institution's service desk
...
- to have an
...
- authorised employee verify his identity
...
- .
- This employee will
...
- bind
...
- the user's token to his account.
...
- After that the user's
...
- token will be activated.
...
- Now the user can log in to any
...
SURFconext Strong Authentication supports three different types of tokens: SMS, Tiqr, YubiKey.
| Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Section |
|---|
The architecture of the SURFconext Strong Authentication is designed as such that SURFnet can add other authentication tokens in the future. If such a need arises within member institutions, SURFnet will first research technical capabilities of other token solutions and perform a cost-benefit analysis, before deciding if adding the extra token to SURFconext is indeed feasible. Please note that SURFconext Strong Authentication is designed to facilitate strong authentication for cloud applications. As such, for any new token solution to be connected to SURFconext Strong Authentication, SAML2.0 compliancy and cloud based are necessary prerequisites. Our roadmap already foresees in some activities in 2016 and beyond to explore the possibilities to add other authentication tokens to SURFconext Strong Authentication. |
...
- service with a level of assurance lower or equal to LoA2 or LoA3 (depending on the registered token).