Introduction
Connecting to the SURFsecureID gateway is very similar to connecting to SURFconext. The are only small differences:
- you will need other SAML metadata.
- there are other optional features in the SAML protocol messages
- there are other SAML features
- there are differences in SURFconext features available when authenticating
When you need different LoA's, more work may be involved. The SP must communicate the required LoA to the SURFsecureID gateway and verify the strength at which a user was authenticated. Both are expressed in the SAML request and response messages that are exchanged between the SP and SURFsecureID.
Levels of Assurance
Regarding to the levels of assurance, there are three scenarios, explained below. They can be combined: the gateway will use then the scenario having the highest LoA.
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 must ask SURFnet to set this minimum. SURFnet will configure this on the SURFsecureID gateway.
2. Minimum LoA specified by SP (static)
The SP requires always a certain minimum LoA.
The SP must ask SURFnet to set this minimum. SURFnet will configure this on the SURFsecureID gateway.
3. LoA defined during authentication (dynamic)
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 is assigned to an identifier and is different for each type of environment used:
| Test | Pilot | 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 requested LoA is interpreted as a minimum. The SURFsecureID gateway:
- 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 required is passed to the SURFsecureID gateway in an AuthnContextClassRef element in a RequestedAuthnContext element in the SAML AuthnRequest.
The identifiers are used in SAML messages communicating the LoA between the SURFsecureID gateway and SP. The actual method of authentication itself (e.g. SMS + password) is not communicated!
- 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: