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://surfconext.nl/assurance/loa1 | |
LoA 2 | http://pilot.surfconext.nl/assurance/loa2 | http://surfconext.nl/assurance/loa2 |
LoA 3 | http://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 aAuthenticationContext
in the SAMLAssertion
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 aRequestedAuthnContext
in a SAMLAuthnRequest