When using SURFconext strong authentication your service must connect to the SURFconext strong authentication gateway (sa-gw.surfconext.nl). 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.
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.
Because the SURFconext Strong Authentication gateway is a separate SAML endpoint, it has different SAML 2.0 metadata. Thus 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
The SP initiates authentication by sending a SAML authentication request to the SURFconext Strong Authentication gateway. IdP initiated login is not supported.
The SAML authentication request from the SP to SURFconext Strong Authentication gateway must be signed. The signature algorithm to be used is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
. The key used for signing should be published in the metadata of the SP as X509Certificate. The RSA key used for signing should have a modulus of 2048 bits or more.
Selecting a binding using a AssertionConsumerServiceIndex
attribute is not supported
The SURFconext String Authentication does not provide Single Sign on for the second factor. That means that for each authentication request for a LoA > 1 the user must authenticate using his secon factor. Setting ForceAuthn
to true MAY force a re-authentication of the user at the institutional IdP, but this cannot be guaranteed.
In SURFconext the AuthnStatement
in the SAML Response
may have a SessionIndex
attribute. The SURFconext Strong Authentication gateway does not provide a SessionIndex
in the SAML Response that is returned to the SP.
More information on the SessionIndex
attribute can be found at line 1107 in https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf
The SURFconext Strong Authentication 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:
http://surfconext.nl/assurance/loa1
http://surfconext.nl/assurance/loa2
http://surfconext.nl/assurance/loa3
Note that non-production (e.g. pilot, test) systems use different identifiers.
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:
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Responder
with second level StatusCode
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
to indicate that a failure during authentication. Used when the user cancels authentication at the gateway.StatusCode
urn:oasis:names:tc:SAML:2.0:status:Requester
with second level StatusCode
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
to indicate that authentication cannot be performed at the requested LoA.The SAML bindings that are supported by SURFconext strong authentication are limited to those in the Interoperable SAML 2.0 Web Browser SSO Deployment Profile. This means that:
HTTP-REDIRECT
binding. The HTTP-POST
binding is not supported for sending an AuthnRequest
;HTTP-POST
binding.Some SURFconext features are unavailable: