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.
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
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
Some SURFconext metadata related features are unavailable when using the Strong Authentication gateway:
- IdP selection though metadata (Transparant metadata, dutch scoping)
- Virtual organisation (VO) selection though VO specific metadata
Authentication Request
The SP initiates authentication by sending a SAML authentication request to the SURFconext Strong Authentication gateway.
IdP initiated login
IdP initiated login is not supported.
Signing
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.
AssertionConsumerServiceIndex
Selecting a binding using a AssertionConsumerServiceIndex
attribute is not supported
ForceAuthn
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.
Scoping using IDPList
Selecting IdP(s) by adding a IDPList
in the Scoping
element in a AuthnRequest
is not supported. This may be supported in future versions.
No SessionIndex in the AuthnStatement
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
AuthenticationContext in the Assertion
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:
- 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:
- First level
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Responder
with second levelStatusCode
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. - First level
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Requester
with second levelStatusCode
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
to indicate that authentication cannot be performed at the requested LoA.
Supported SAML Bindings
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:
- The SP must send SAML Authentication Requests using the
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
binding. Theurn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
binding is not supported for sending anAuthnRequest
; - The SP must be able to receive SAML Responses using the
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
binding.