...
A service can connect to SURFconext or SURFsecureID to handle it's strong authentication login. There are only a few differences between both options. But whenever possible, connect your service to SURFconext as this is the preferred methodPreviously, it was also possible to connect a service to SURFsecureID directly, but this has been deprecated. All necessary (and more) functionality to enable SURFsecureID for a service can be handled by SURFconext.
With SURFsecureID, the login process will not only perform the first factor (username/password at the institution's Identity Provider), but also the second factor as chosen by the end user.
...
The service connects to SURFconext
Many services are already connected to SURFconext or can easily make such a connection. The service provider or the institution consuming the service can determine that strong authentication is needed for accessing the service. Enabling SURFsecureID can be done by the SURFconext-responsible person ("SURFconext-verantwoordelijke") from the institution in the SURFconext Dashboard by going to the specific service, go to the SURFsecureID tab and select an appropriate Level-of-assurance. The institution or service provider do not need to make any changes to their implementations.
Note that:
- This option is preferred above option B
- The service can connect with SAML or OpenID Connect to SURFconext, both will work
- A step-up policy can be configured in SURFconext that determines for which persons SURFsecureID is called. This can be configured based on user-attributes or IP adres. See option 2 on this page.
- This integration does not also supports dynamic LoA request by the service. If the service wants to use this feature it needs to connect to SURFsecureID directly (see option B).
- This option works for the production and test environment, not for the pilot environment.
...
- The SP sends a SAML 2.0 AuthnRequest or an OpenID Connect request to SURFconext.
- The user chooses the Identity Provider (institution) where to login for the 1st factor and SURFconext sends this IdP a SAML AuthnRequest
- The user logs in at the IdP and a SAML response is sent back to SURFconext with the identity and attributes of the user
- In this case, SURFconext is configured for this SP or SP-IDP combination to call SURFsecureID with a minimum LoA (>1).
- SURFsecureID gateway sends the user to the authentication provider for the 2nd factor
- The 2nd factor authentication provider returns the response to the SURFsecureID gateway.
- The SURFsecureID gateway sends a SAML Response back to SURFconext
- SURFconext sends a SAML or OpenID Connect Response with Assertion and the attributes and the identity of the user to the SP.
...
Note that the SP chooses where to send the AuthNrequest (i.e. SP initiated authentication).
...
(DEPRECATED) The service connects to SURFsecureID
| Info |
|---|
For test and production systems, there is no need any more to connect a service directly to SURFsecureID. Instead, connect the service directly to SURFconext and configure SURFsecureID there. All (and more) functionality is present in SURFconext to protect a service with SURFsecureID. For the SURFsecureID pilot environment, it is still necessary to connect the service to SURFsecureID directly. |
Usually, a Service Provider and institution together determine if strong authentication is needed for a specific service. The Service Provider can connect its service to the SURFsecureID endpoint, and the institution makes sure the users are properly registered with their strong authentication token. Institutions do not need to make any changes to their Identity Providers to implement this option.
...