The normal SURFconext (aka engine) and SURFsecureID are engine.surfconext.nl) and SURFsecureID (sa-gw.surfconext.nl) are both SAML proxies. If you are migrating a SP from SURFconext to SURFsecureID, you should be aware that there are differences between these two SAML proxies.
Please note that SURFsecureID does not yet support OpenID Connect whereas SURFconext does. If you must use OpenID Connect, an OpenID Connect - SAML proxy may be an option (like SaToSa).
Architecture
The image below shows how SURFconext and SURFsecureID relate to each other. An authentication to SURFsecureID (route 1) will pass though the normal SURFconext. This means that SURFconext functionality like consent, authorization, attribute aggregation function functions just like an 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 it received the SAMLResponse. If your SAML library supports the IdP initiated flow (a.k.a unsollicited assertions), your SP could receive, and accept as valid, a SAMLResponse from any trusted IdP at any time. |
Metadata
Because the SURFsecureID 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.
...
The attributes you receive from SURFsecureID come from the normal SURFconext. SURFsecureID requires that your SP receives the eduPersonTargetedID (EPTI) attribute. If this attribute is not present, the authentication will fail at the SURFsecureID gateway.
| Warningnote | ||||
|---|---|---|---|---|
| ||||
Ensure that you receive the eduPersonTargetedID (EPTI) attribute when migrating your SP from SURFconext to SURFsecureID. This attribute is required for SURFsecureID. You can ask support@surfconext.nl to enable this attribute for your SP. |
...
Single Sign on for the second factor is not provided: for each authentication request with a LoA > 1 the user must always authenticate using his second factor.
...
Because your SP can still use the normal SURFconext, you could first authenticatie 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 reauthenticatie at the IdP.
...