Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Differences between 'standard' SURFconext Strong Authentication and SFO authentication

FeatureStandard authenticationSFO authenticaton
Authentication of first factorAlwaysNever
Authentication of second factorBased on policy between IdP and SPAlways
User registrationUsing SURFconext Strong Authentication selfservice registration and vetting by an RA
Standard SURFconext featuresAttributes, Authorization, persistent identifiersNone

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: