Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • 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 also supports dynamic LoA request by the service.
  • This option works for the production and test environment, not for the pilot environment.

Authentication flow

  1. The SP sends a SAML 2.0 AuthnRequest or an OpenID Connect request to SURFconext.
  2. The user chooses the Identity Provider (institution) where to login for the 1st factor and SURFconext sends this IdP a SAML AuthnRequest
  3. The user logs in at the IdP and a SAML response is sent back to SURFconext with the identity and attributes of the user
  4. In this case, SURFconext is configured for this SP or SP-IDP combination to call SURFsecureID with a minimum LoA (>1).
  5. SURFsecureID gateway sends the user to the authentication provider for the 2nd factor
  6. The 2nd factor authentication provider returns the response to the SURFsecureID gateway.
  7. The SURFsecureID gateway sends a SAML Response back to SURFconext
  8. SURFconext sends a SAML or OpenID Connect Response with the attributes and the identity of the user to the SP.



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.