SURFsecureID and SURFconext uss Levels of Assurance (LoA) to express the strength of the authentication of a user. This page describes how a service or institution can request a LoA for a specific service or specific authentications to a service.

How to request authentication at a Level of Assurance?

A service can communicate the required level of assurance (LoA) for the authentication of a user to SURFconext and SURFsecureID and verify the strength at which a user was authenticated.

There are several scenarios how to request a LoA, explained below. They can be combined: SURFsecureID and SURFconext will use the highest LoA that results from these scenario's. I.e. it is only possible to raise the LoA requirement for an authentication, never to lower it.

1. Minimum LoA specified by the institution (static)

The institution requires, for a specific SP, its users always to be authenticated at a certain minimum LoA.

The institution uses the SURFconext dashboard to set a minimum required LoA for all authentications to a service.

2. Minimum LoA specified by SP (static)

The SP requires users always to be authenticated at a certain minimum LoA. The SP must ask SURF (support@surfconext.nl) to set this minimum on their behalf.

3. LoA defined during authentication (dynamic)

A SP can request authentication at a certain LoA by specifying it in the SAML AuthnRequest. The SP can send this request to the gateway at any time, also when a user is already logged in. This "stepup authentication" makes it possible to raise the LoA for a user depending on the context, e.g. if the user wants to enter the admin part of the site.

The LoA is passed to SURFconext in the AuthnContextClassRef element in a RequestedAuthnContext element in the SAML AuthnRequest.

4. LoA based on policy rules in SURFconext (dynamic)

An institution or service can request policy rules to be configured in SURFconext (support@surfconext.nl)) that determine the required LoA for an authentications. These policy rules can use the value of the user's attributes (e.g. affiliation, entitlement) and IP address as a basis for the LoA descision. This allows stepup rules based on information from the institution as well from sources like SURFconext Invite to be used in the LoA policy.

The requested LoA is interpreted as a minimum. SURFconext and SURFsecureID:

• Will not perform authentication below the requested loA.
• May perform authentication at a higher level, in which case the higher level LoA will be expressed in the returned SAML Assertion.

The LoA identifiers are used in SAML messages communicating the LoA between SURFconext/SURFsecureID and the SP. The actual method of authentication itself (e.g. SMS + password) is not communicated.

• SURFconext/SURFsecureID will report to the SP the actual LoA at which the authentication was performed. This is done with the AuthnContextClassRef element of AuthenticationContext in the SAML Assertion in the SAML response.

Standard Authentication LoA's

Four levels of assurance (LoA) are supported:

• LoA 1: Only password authentication at the institution's IDP
• LoA 1.5: LoA 1 + any SURFsecureID second factor, no extra validation of the user's identity 
• LoA 2: LoA 1 + SMS, Tiqr or AzureMFA authentication AND the identity of the user is validated
• LoA 3: LoA 1 + YubiKey or FIDO2 (hardware token) authentication AND the identity of the user is validated

Each LoA is assigned to an identifier and is different for each type of environment used:

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

http://surfconext.nl/assurance/loa1

http://test.surfconext.nl/assurance/loa1.5

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

http://test.surfconext.nl/assurance/loa2

http://surfconext.nl/assurance/loa2

http://test.surfconext.nl/assurance/loa3

http://surfconext.nl/assurance/loa3

These identifiers are used to communicate the strength of authentication between the SURFconext and the Service Provider. The actual method of authentication (e.g. SMS + password) at the institutional IdP is not communicated.

• The SURFsecureID gateway will report the LoA at which authentication was performed to the SP in a AuthnContextClassRef element in a AuthenticationContext in the SAML Assertion.
• A SP may request authentication at a specific LoA by specifying the identifier in a AuthnContextClassRef element in a RequestedAuthnContext in a SAML AuthnRequest. See SAML message examples for an example AuthnRequest that requests authentication at a specific LoA.

Second Factor Only (SFO) authentication LoA's

The identifiers below are exclusively for use by SPs that connect directly to the SURFsecureID gateway's SFO endpoint.

With Second Factor Only (SFO) Authentication "level" is used to indicate the authentication strength of the second factor:

• Level 1.5: any SURFsecureID second factor, no extra validation of the user's identity 
• Level 2: SMS, Tiqr or AzureMFA authentication AND the identity of the user is validated
• Level 3: YubiKey or FIDO2 (hardware token) authentication AND the identity of the user is validated

The following identifiers are used:

http://test.surfconext.nl/assurance/sfo-level1.5

http://surfconext.nl/assurance/sfo-level1.5

http://test.surfconext.nl/assurance/sfo-level2

http://surfconext.nl/assurance/sfo-level2

http://test.surfconext.nl/assurance/sfo-level3

http://surfconext.nl/assurance/sfo-level3