Page tree

Versions Compared


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

This part of the wiki gives all the (technical) information that can be of importance for Service Providers working with SURFconext Strong AuthenticationSURFsecureID.

  • To start with it is explained how you can connect your service with the Strong Authentication the SURFsecureID gateway. Actually it is very similar to the 'normal' way of connecting to SURFconext. The are only small differences, like using other metadata. Also you will have to tell the gateway the required Level of assurance (LoA1, LoA2 or LoA3). For an overview of all the differences between SURFconext Strong Authentication between SURFsecureID and the 'normal' SURFconext authentication procedure, have a look on this page.
  • Else in the wiki we already described the concept of levels of assurance. Here you will find the (technical) details needed to communicate the strength of authentication between the SURFconext Strong Authentication the SURFsecureID gateway and the Service Provider.
  • With SURFconext Strong Authentication With SURFsecureID you have also the possibility to have second factor only authentication. In that case the first factor authentication (username and password) is done at the IdP (and not at SURFconext). We explain the differences between second factor only authentication and the 'normal' authentication. After that the SAML AuthRequest and SAML response for second factor only authentication are explained. Also you can read how to implement second factor only authentication and finally you will find a link to an example.
  • To be able to use SURFconext Strong Authentication use SURFsecureID metadata is needed. There are three sets of metadata: one for the Production environment, one for the Test environment and another one for second factor only authentication.
  • On the next page we give examples of an authentication request at a specific LoA, You will see also two examples of the SAML response in case of an authentication failure.
  • You can use SimpleSAMLphp to request a specific minimum level op assurance (LoA) from the Strong Authentication the SURFsecureID gateway and to verify the LoA at which the user is authenticated. For both instances you will find an example.
  • If you use Shibboleth as your sign-on system, you can read here how to configure it for SURFconext Strong AuthenticationSURFsecureID.
  • For testing your connection to SURFconext Strong Authentication to SURFsecureID you should not use any 'regular' account, but a special Onegini account.