The normal SURFconext (aka engine) and SURFconext Strong Authentication (SURFconext SA) are both SAML proxies. If you are migrating a SP from the normal SURFconext to SURFconext Strong Authentication, you should be aware that there are differences between these two SAML proxies.
Architecture
The image below shows how SURFconext and the SURconext Strong Authentication (SURFconext SA) relate to each other. An authentication to SURFconext SA (route 1) will pass though the normal SURFconext. This means that SURFconext functionality like consent, authorization, attribute aggregation function just like an authentication to SURFconext (route 2).
A service that uses SURFconext Strong Authentication directly (route 1 in the image below) 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 SURFconext SA.
Metadata
Because the SURFconext Strong Authentication proxy is a separate SAML IdP from the normal SURFconext, it has different SAML 2.0 metadata. The EntityID, SAML signing certificate and Single Sign On Location are all different from the normal SURFconext.
This means that some metadata related features are unavailable when using the SURFconext Strong Authentication gateway:
- IdP selection through metadata (transparent metadata, Dutch scoping)
Attributes
The attributes you receive from SURFconext Strong Authentication come from the normal SURFconext. SURFconext SA requires that your SP receives the eduPersonTargetedID (EPTI) attribute.
Ensure that you receive the eduPersonTargetedID (EPTI) attribute when migrating your SP from SURFconext to SURFconext SA. This attribute is required for SURFconext SA. You can ask support@surfconext.nl to enable this attribute for your SP.
Authentication Request
Signing
The authentication request must be signed with the following algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
. The RSA key used for signing should be published in the metadata of the SP as X509Certificate. The RSA public key must have a modulus of 2048 bits or more.
AssertionConsumerServiceIndex
Selecting a binding using the AssertionConsumerServiceIndex
attribute is not supported.
ForceAuthn
Single Sign on for the second factor is not provided: for each authentication request with a LoA > 1 the user must authenticate using his second factor.
Setting ForceAuthn
to true may force a re-authentication of the user at the institutional IdP for the first factor, but this cannot be guaranteed.
No SessionIndex in the AuthnStatement
The SURFconext Strong Authentication gateway does not provide a SessionIndex
in the SAML Response returned to the SP. More information (see at line 1107).
IdP initiated login
SURFconext Strong Authentication does not support IdP initiated login (IdP-geïnitieerde login).
Because your SP can still use the normal SURFconext, you could first authenticatie the user there and then authenticate the user at SURFconext SA. 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 reauthenticatie 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 authenticatie the user there and then authenticate the user at SURFconext SA. Because the user has SSO at the IdP, and SURFconext remebers the selected IdP the user wil not get a WAYF (IdP selection screen) and does not need to reauthenticatie at the IdP.
AuthenticationContext in the Assertion
After successful authentication the SURFconext Strong Authentication gateway will report the level of assurance in an AuthnContextClassRef
element in an AuthenticationContext
in the SAML Assertion
sent to the SP.
Non-production environments use different identifiers!
Authentication failure
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 SURFconext Strong Authentication 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
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Responder
with second levelStatusCode
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed:
user canceled authentication.
or - First level
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Requester
with second levelStatusCode
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext:
authentication cannot be performed at the requested LoA.
More info:
Supported SAML bindings
The SAML bindings supported 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
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
.urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
is not supported. - The SP must be able to receive SAML Responses using the
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
binding.