This page describes the differences between SURFconext and SURFsecureID that are relevant for a SAML service provider (SP) that is migrating from SURFconext to the SURFsecureID gateway, or that is using both simultaneously.
Note that this connecting to SURFsecureID directly is deprecated for the SURFsecureID test and production environments.
Architecture
SURFconext (engine.surfconext.nl) and SURFsecureID When using SURFconext strong authentication your service must connect to the SURFconext strong authentication gateway (sa-gw.surfconext.nl) are both SAML proxies. This gateway is a SAML 2.0 IdP that offers authentication services to your service – a SAML 2.0 SP. The SURFconext strong authentication gateway is a different gateway than the SURFconext gateway (engine.surfconext.nl).
If you are migrating a SP from SURFconext to SURFconext Strong Authentication or when you are adapting example from the SURFconext documentation it is good to be aware of the differences between the two gateways.
Differences
Below is a detailed list of differences between the SAML features suppored by SURFconext as described in Authentication request options and SAML Response and Assertion and the Strong Authentication gateway.
Metadata
The image below shows how SURFconext and SURFsecureID relate to each other.
Your SP connects to the IdP side of the proxy. An authentication to SURFsecureID (route 1) will pass though SURFconext. This means that SURFconext functionality like consent, authorization, attribute aggregation functions just like a direct authentication to SURFconext (route 2).
A service that uses SURFsecureID directly (route 1 in the image below) thus can continue to use SURFconext for authentication (route 2 in the image below). It is your SP that, for each authentication, decides which route it wants to use. The SP will receive the same attributes and user identifiers regardless of the route it takes. To get strong authentication your SP must authenticate to SURFsecureID.
| Warning | ||
|---|---|---|
| ||
If your SP trusts multiple IdPs (e.g. SURFconext IdP and the SURFsecureID IdP), your SP must always verify from which IdP (the |
Metadata
Because the SURFsecureID proxy is a separate SAML IdP from the normal SURFconextBecause the SURFconext Strong Authentication gateway is a separate SAML endpoint, it has different SAML 2.0 metadata. Thus the The EntityID, SAML signing certificate and Single Sign On Location are all different . The metadata can be found at: https://sa-gw.surfconext.nl/authentication/metadata
Authentication Request
The SP initiates authentication by sending a SAML authentication request to the SURFconext Strong Authentication gateway. IdP initiated login is not supported.
Signing
...
from the normal SURFconext.
This means that some metadata related features are unavailable when using the SURFsecureID gateway:
- IdP selection through metadata (transparent metadata, Dutch scoping)
Attributes
The attributes you receive from SURFsecureID are supplied by SURFconext.
Authentication Request
AssertionConsumerServiceIndex
Selecting a binding using a the AssertionConsumerServiceIndex attribute attribute is not supported.
ForceAuthn
The SURFconext String Authentication does not provide Single Sign on for the second factor . That means that is not provided: for each authentication request for with a LoA > 1 the user must always authenticate using his secon second factor. Setting
Setting ForceAuthn to to true MAY may force a re-authentication of the user at the institutional IdPIdP for the first factor, but this cannot be guaranteed.
No SessionIndex in the AuthnStatement
In SURFconext the AuthnStatement in the SAML Response may have a SessionIndex attribute. The SURFconext The SURFconext Strong Authentication gateway gateway does not provide a a SessionIndex in in the SAML Response that is returned to the SP. More information on the SessionIndex attribute can be found (see at line 1107 in https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf).
IdP initiated login
SURFsecureID does not support IdP initiated login (IdP-geïnitieerde login).
Because your SP can still use the SURFconext, you could first authenticate the user there and then authenticate the user at SURFsecureID. Because the user has SSO at the IdP, and SURFconext remembers the selected IdP the user will not get a WAYF (IdP selection screen) and does not need to reauthenticate at the IdP.
Scoping using IDPList
Selecting IdP(s) by adding a IDPList in the Scoping element in a AuthnRequest is not supported.
Because your SP can still use the normal SURFconext, you could first authenticate the user there and then authenticate the user at SURFsecureID. Because the user has SSO at the IdP, and SURFconext remembers the selected IdP the user wil not get a WAYF (IdP selection screen) and does not need to reauthenticate at the IdP.
AuthenticationContext in the Assertion
The SURFconext Strong Authentication After successful authentication the SURFsecureID gateway will report the actual level of assurance (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.
The LoA identifiers used are:
- LoA 1:
http://surfconext.nl/assurance/loa1 - LoA 2:
http://surfconext.nl/assurance/loa2 - LoA 3:
http://surfconext.nl/assurance/loa3
Note that non-production (e.g. pilot, test) systems use different identifiers.
SAML Response with error StatusCode
SURFconext Strong Authentication gateway uses a SAML Response with an non-success StatusCode to communicate some typical failures that can occur during authentication back to the SP. A an SP must be prepared to deal with these. Two error responses are currently in use:
in an AuthnContextClassRef element in an AuthenticationContext in the SAML Assertion sent to the SP.
Non-production environments use different identifiers!
| Anchor | ||||
|---|---|---|---|---|
|
When authentication fails, it is generally because the user:
- cancels authentication during verification of the second factor or
- does not have a suitable second factor identification
The SURFsecureID gateway will send a SAML Response to the SP about the failure. The SP should be ready to handle the response. The response contains non-success StatusCodes:
...
- First level
StatusCodeurn:oasis:names:tc:SAML:2.0:status:Responder
with second
...
- level StatusCode
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
...
- : user canceled the authentication.
or - First level
StatusCodeurn:oasis:names:tc:SAML:2.0:status:
...
Responder
with second
...
- level
StatusCodeurn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
...
- : authentication cannot be performed at the requested LoA.
More info:
Supported SAML
...
bindings
The SAML bindings that are supported by SURFconext strong authentication are limited to those in the the Interoperable SAML 2.0 Web Browser SSO Deployment Profile. This means that:
- The SP must send SAML Authentication Requests using the
HTTP-REDIRECTbinding. TheHTTP-POSTbinding is not supported for sending anAuthnRequest;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect.urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTis not supported. - The SP must be able to receive SAML Responses using the the
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTbinding.
SURFconext features
Some SURFconext features are unavailable:
...
- binding.