You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

For expressing the "strength" of the authentication and the identity of the user a assurance framework as described in ISO/IEC 29115 is used (similar to NIST Special Publication 800-63-1). The SURFconext Strong Authentication gateway will Support 3 levels of assurance (LoA):

  • LoA 1: Password authentication through SURFconext at the user's home IdP
  • LoA 2: LoA 1 + SMS or Tiqr authentication
  • LoA 3: LoA 1 + YubiKey (hardware token) authentication

Each LoA is assigned a unique identifier. The following identifiers are used:

 Pilot (test)Production
LoA 1

http://pilot.surfconext.nl/assurance/loa1

http://surfconext.nl/assurance/loa1
LoA 2http://pilot.surfconext.nl/assurance/loa2
http://surfconext.nl/assurance/loa2
LoA 3http://pilot.surfconext.nl/assurance/loa3
http://surfconext.nl/assurance/loa3

Communication regarding the strength of authentication between SURFconext Strong Authentication and the service provider is done using these identifiers. At no point is the actual method of authentication (e.g. SMS + password) communicated between the SP and SURFconext. This is intentional, it is expected that authentication methods will be added, and removed during the lifetime of the SURFconext Strong Authentication service. The LoA identifiers should remain stable.

The identifiers are used in SAML protocol messages to communicate the LoA between the SURFconext Strong Authentication gateway and a SP.

  • The SURFconext Strong Authentication gateway will report the actual LoA at which authentication was performed in a AuthnContextClassRef element in a AuthenticationContext in the SAML Assertion that the SP receives from the SURFconext Strong Authentication gateway after successful authentication.
  • A SP may request authentication at a specific LoA by specifying one of the defined LoA identifiers in a AuthnContextClassRef element in a RequestedAuthnContext in a SAML AuthnRequest

Second Factor Only (SFO) authentication

When using Second Factor Only (SFO) Authentication the second factor only endpoint different identifiers are used. Because in this scenario the SA gateway only performs part of the authentication process the LoA assurances do not apply. Instead of LoA we use the term "level" to indicate the authentication strength of the second factor.

The levels map to the second factors of the corresponding LoA level:

  • Level 2: SMS or Tiqr authentication
  • Level 3: YubiKey (hardware token) authentication

Each level is assigned a unique identifier. The following identifiers are used:

 Pilot (test)Production
Level 2
http://pilot.surfconext.nl/assurance/sfo-level2
http://surfconext.nl/assurance/sfo-level2
Level 3
http://pilot.surfconext.nl/assurance/sfo-level3
http://surfconext.nl/assurance/sfo-level3
 

 

  • No labels