...
A SP can request authentication at a certain LoA by specifying it in the AuthnRequest. The SP can send this request to the gateway at any time, also when a user is already logged in. This 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.
Three levels of assurance
...
- LoA 1: Password authentication through SURFconext at the users home IdP
- LoA 2: LoA 1 + SMS or Tiqr authentication
- LoA 3: LoA 1 + YubiKey (hardware token) authentication
Each LoA has a unique identifieris assigned to an identifier and is different for each type of environment used:
| Test | Pilot (test) | Production | |
|---|---|---|---|
| LoA 1 | http://test.surfconext.nl/assurance/loa1 |
| http://surfconext.nl/assurance/loa1 |
| LoA 2 | http://test.surfconext.nl/assurance/loa2 | http://pilot.surfconext.nl/assurance/loa2 | http://surfconext.nl/assurance/loa2 |
| LoA 3 | http://test.surfconext.nl/assurance/loa3 | http://pilot.surfconext.nl/assurance/loa3 | http://surfconext.nl/assurance/loa3 |
...
- The SURFsecureID gateway will report the SP the actual LoA at which authentication was performed. This is done with the AuthnContextClassRef element of AuthenticationContext in the SAML Assertion.
- A SP may request authentication at a specific LoA by specifying the LoA identifier in a AuthnContextClassRef element in a RequestedAuthnContext in a SAML AuthnRequest.
...
More info: