...
Second Factor Only authentication allows a SP to authenticate only the second factor of a user. With SFO you can add two factor authentication to your institutions application gateway (e.g. Citrix Netscaler or F5 BIG-IP) or to the authentication or authorization gateway (e.g. Microsoft ADFS or Novell/NetIQ). SFO has its own authentication endpoint at SURFconextSURFsecureID.
Once a user is registered with a second factor both SFO authentication and SURFconext Strong Authentication can and SURFsecureID can be used.
Differences between 'standard'
...
SURFsecureID and SFO authentication
| Feature | Standard authentication | SFO authenticaton |
|---|---|---|
| Authentication of first factor | Always | Never |
| Authentication of second factor | Based on policy between IdP and SP | Always |
| User registration | Using SURFconext Strong Authentication SURFsecureID selfservice registration and vetting by an RA | |
| Standard SURFconext features | Attributes, Authorization, persistent identifiers | None |
...
To start a SFO the SP must send a SAML 2.0 AuthnRequest to the SFO endpoint of the SURFconext Strong Authentication the SURFsecureID Gateway. This request must:
...
When a user cannot be authenticated, the SURFconext Strong Authentication the SURFsecureID gateway sends a SAML Response to the SP with a non success status:
...
SFO must be implemented at the SP. The authentication protocol is similar to the one used by the Strong Authentication the SURFsecureID gateway. The main difference is that the SP must send the identifier of the user in the Subject element of the SAML AuthnRequest (see description of AuthnRequest, line 2017).
- The SP will be registered at the SURFconext Strong Authentication the SURFsecureID gateway as either SFO SP or a 'standard' SURFconext Strong Authentication SURFsecureID SP: this determines which endpoint he can access. If a SP implementation needs both, he can register an additional EnityID and use it to access the other endpoint.
- There is a white-list of SURFconext identities allowing SFO authentication. The SP must indicate in advance the institutions from which he wants to authenticate users with SFO.
You can find the metadata of the SFO endpoints on Surfconext Strong Authentiation SURFsecureID Metadata for Service Providers.
...
Starting an SFO authentication will immediately start an authentication at the SURFconext Strong Authentication the SURFsecureID gateway: a push notification (tqr) or an SMS will be sent to the user being authenticated. If authentication is started for the wrong user, this will derange the targeted user and in case of SMS, incur a cost to the institution and possibly for the user.
...
An example code for using SFO with SimpleSAMLphp can be found at: https://github.com/SURFnet/Stepup-SFO-demo