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
- 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. - 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. - The SA-GW receives a response from SURFconext (IdP1) with the identity and attributes of the user.
- The SA-GW determines whether strong authentication is required and if so sends the user to the authentication provider (IdP2) for the 2nd factor.
- The 2nd factor authentication provider (IdP2) returns the response to the SA-GW.
- 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).