...

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

 Image Added

Image Removed

Note that:

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

Anchor
Authentication flow Authentication flow

Authentication flow

Image Modified

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

...

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