You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

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 through metadata (Transparent metadata, dutch scoping)
  • Virtual organisation (VO) selection through 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 Strong 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 second 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 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.
  • First level 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.

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. The urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST binding is not supported for sending an AuthnRequest;
  • The SP must be able to receive SAML Responses using the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST binding.

 

 

 

  • No labels