...
- 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 SURFsecureID 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?
...
Can a second factor authentication be re-used in one browser session?
No. For reasons of simplicity, transparency and security SURFsecureID 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.
...
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 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?
...
Can an institution re-use its own strong authentication tokens?
No, SURFsecureID 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, SURFsecureID has succesfully carried out a proof-of-concept with Vasco and Azure MFA to use their tokens with SURFsecureID. 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?
...
How can I order YubiKey tokens?
There are several options where you can buy YubiKeys.
...
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.