Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

When a user logs in, the SP will send a SAML 2.0 authentication request (AuthnRequest) to SURFconext. Below you will find detail information about the supported bindings, the signing and the available options.

Table of Contents

Supported bindings

SURFconext supports two types of bindings:

  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect (preferred in accordance to SAML2int profile)
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST (can only be used in case your software doesn't support HTTP-Redirect)


By default, the signature on AuthnRequests is ignored. Some use cases and features require AuthnRequest however to be signed. Contact SURFconext support to enable this.

  • Currently SHA256 signing is supported:
  • The SP must provide the public RSA key required for verification of the signature out of band, preferably using SAML metadata.
  • The key must be provided an X.509 certificate in PEM format.
  • Certificates should be self signed and valid (= not expired).
  • SURFconext retrieves only the public key from the certificate. No other validation is done.
  • The public modulus of the RSA key must be 2048 or 4096 bits.
  • SURFconext can register two trusted certificates per SP.

Authentication request options

You can use the following options in AuthnRequest:


This method is not allowed in the saml2int profile (see above). Use AssertionConsumerServiceURL instead.


This attribute is used to specify an alternate AssertionConesumerService Location for the resulting SAML response. This can be any location from the SP metadata registered in SURFconext. When signature verification of AuthnRequest is enabled, the SP is allowed to request any AssertionConesumerService Location.

If no AssertionConsumerService is specified, SURFconext will use the default from the SP metadata registered in SURFconext.


With the ForceAuthn parameter you can disable single sign-on. If a user is already logged in and he tries to log in for another service at SURFconext, he will have to authenticate again at his home IP.

To disable single sign-on both AuthnRequests must be signed: (1) the AuthnRequest from SP to SURFconext and (2) the resulting AuthnRequest from SURFconext to the home IP. By default signing is disabled: contact SURFconext support to enable it. SURFconext can also contact the home IPs involved: they must enable signing of AuthnRequests on their side.


Not supported.



The value of AllowCreate is ignored.


You can specify a format attribute in the NameIDPolicy parameter:

  • If specified and if the format is in the list of allowed NameIDFormats it will be used. Otherwise the default NameID format (urn:oasis:names:tc:SAML:2.0:nameid-format:transient only) will be used.
  • If not specified, the default format will be used.


Is currently ignored .However, we recommend not to send it if it does not serve a specific purpose: in the future it may be passed transparently by default. On request we can enable it to be transparent, and any value set will be transparently copied to the Identity Provider who may or may not act on it.


This element is used to restrict the IdPs available though a proxying IdP (like SURFconext). The only elements supported are RequesterID and IDPList:


This element can be used for a SP performing authentication on behalf of another SP (SP proxy). RequesterID contains the EnityID of a SP. This EntityID must be registered at SURFconext and meet all requirements for a SP, except the SAML endpoint information (e.g. AssertionConsumerService Location). The IdPs available are restricted to the ones that have access to both SPs. For a SP to be in that selection rely it needs to ensure that a malicious user can not circumvent the restriction by modifying the AuthnRequest, which can be done in two ways:

  1. Signing the AuthnRequest and requesting SURFconext to enable signature validation for the proxying SP.
  2. Verifying that the EntityID in the AuthenticatingAuthority element in the AuthnContext in the SAML Assertion is from an IdP that is allowed access. For a list with EntityIDs of the IdPs that are allowed access to your SP:<the EntityID of your SP>


This element defines the IdPs shown in the SURFconext WAYF. It contains one or more IDPEntry elements with the entityID of the IdP in the ProviderID attribute. The entiyIDs of the available IdPs can be found in the IdPs metadata.

If IDPList contains only one IdP, the WAYF will be skipped and the user will be directed to that IdP.

Note that there is no guarantee that the user will actually be authenticated by one of the IdPs in the IDPList. The IdP used to authenticate the user can be found in the AuthenticatingAuthority element in the AuthnContext in the SAML Assertion.

Code Block
titleAn SAML AuthenRequest using Scoping with an IDPList
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_123456789097da188e1e4016be09fb13c422553cea" Version="2.0"
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
            <samlp:IDPEntry ProviderID=""/>
            <samlp:IDPEntry ProviderID=""/>

Dutch scoping

When a SP cannot support scoping, also the "transparent metadata" at can be used to select a IdP instead of the SURFconext WAYF. This method relies on each IdP having a different SSO Location. A typical use case is a SP having its own WAYF or discovery service (Dutch scoping).


Page Tree
rootSAML reference