Versions Compared

Key

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

Introduction

A service can use SURFconext Strong Authentication use SURFsecureID to handle it's login, much like SURFconext is used to perform user login for services. There are only a few differences between a SURFconext and the SURFconext Strong Authentication the SURFsecureID connection. With SURFconext Strong AuthenticationSURFsecureID, 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.

Usually, a Service Provider and institution together determine if strong authentication is needed for a specific service. The Service Provider connects its service to the SURFconext Strong Authentication 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.

...

The picture below shows the relation between:

  • SURFconext Strong Authentication gatewaySURFsecureID gateway
  • SURFconext gateway
  • SPs 
  • Second factors used for SURFconext Strong Authentication (SMS, Tiqr and YubiKey)

...

  1. The SP sends a SAML 2.0 AuthnRequest to the SURFconext Strong Authentication gateway the SURFsecureID gateway (SA-GW).
    The SP may use a RequestedAuthnConext to specify the minimal LoA at which a user must be authenticated.
  2. The SA-GW sends a Authn request to SURFconext (IdP1).
    SURFconext takes care of the authentication of the user at their home IdP (not shown) and applies policies: attribute release, user consent and institutional consent.
  3. The SA-GW receives a response from SURFconext (IdP1) with the identity and attributes of the user.
  4. The SA-GW determines whether strong authentication is required and if so sends the user to the authentication provider (IdP2) for the 2nd factor.
  5. The 2nd factor authentication provider (IdP2) returns the response to the SA-GW.
  6. The SA-GW sends a SAML Response with Assertion and the attributes and the identity of the user to the SP.

...