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

Compare with Current View Page History

« Previous Version 18 Next »

Metadata

If you are migrating a SP from SURFconext to SURFconext Strong Authentication, you should be aware of the differences between the two gateways.

  • Because the SURFconext Strong Authentication gateway is a separate SAML endpoint, it has different SAML 2.0 metadata: EntityID, SAML signing certificate and Single Sign On Location are different.
  • Some metadata related features are unavailable when using the SURFconext Strong Authentication gateway:
     -  IdP selection through metadata (transparent metadata, Dutch scoping)
     -  Virtual organisation selection through VO specific metadata

Authentication Request

IdP initiated login

Different from the SURFconext gateway, with SURFconext Strong Authentication IdP initiated login is not supported.

Signing

The authentication request must be signed with the following algorithm: 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. It 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.

Scoping using IDPList

Selecting IdP(s) by adding a IDPList in the Scoping element in a AuthnRequest is not supported.

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).

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:

  1. cancels authentication during verification of the second factor or
  2. 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:

  1. First level StatusCodeurn:oasis:names:tc:SAML:2.0:status:Responder
    with second level StatusCodeurn:oasis:names:tc:SAML:2.0:status:AuthnFailed:
    user canceled authentication.
    or
  2. 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:
    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.

 

  • No labels