The picture below shows the relation between:

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

Note that:

• There are no technical changes required for IdPs. They still connect to SURFconext.
• SPs connect to the SURFconext Strong Authentication gateway. No connection with SURFconext or integration with second factor authentication devices is required.

Authentication flow

1. The SP sends a SAML 2.0 AuthnRequest to the SURFconext Strong Authentication 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.

For the SP only steps 1 and 6 are visible.

Note that the SP chooses where to send the AuthNrequest (i.e. SP initiated authentication).