...
Differences between 'standard' SURFconext Strong Authentication 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 selfservice registration and vetting by an RA | |
| Standard SURFconext features | Attributes, Authorization, persistent identifiers | None |
With SFO the authentication via SURFconext is bypassed (see image below). This means that SURFconext functionality (e.g. attributes from the user's home IdP, the definition of authorization rules and persistent user identifiers) is not available.
...
- The SP will be registered at the SURFconext Strong Authentication gateway as either SFO SP or a 'standard' SURFconext Strong Authentication 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 Metadata for Service Providers.
Always do a first factor authentication before starting a SFO authentication
...
An example code for using SFO with SimpleSAMLphp can be found at: https://github.com/SURFnet/Stepup-SFO-demo