• Created by Unknown User (urn:collab:person:surfguest.nl:d09fa6a3-58f5-48a7-aa62-17f02489c888), last modified by Teun Fransen on Mon 09 Jan 2017

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

Compare with Current View Page History

« Previous Version 25 Next »

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.

Supported bindings

SURFconext supports two types of bindings:

  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect (preferred binding in accordance to SAML2int profile)
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Signing

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.

  • Two signing algorithms are supported: http://www.w3.org/2000/09/xmldsig#rsa-sha1 and http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
  • 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:

AssertionConsumerServiceIndex

This attribute is used to specify an alternate binding and AssertionConesumerService Location for the resulting SAML response by specifying an index in the SAML metadata. Use of this method is strongly discouraged. Use AssertionConsumerServiceURL instead.

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

AssertionConsumerServiceURL

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.

ForceAuthn

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.

IsPassive

Not supported.

NameIDPolicy

AllowCreate

The value of AllowCreate is ignored.

Format

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.

RequestedAuthnContext

This parameter is ignored.

Scoping

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

RequesterID

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: https://engine.surfconext.nl/authentication/proxy/idps-metadata?sp-entity-id=<the EntityID of your SP>

IDPList

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.

An SAML AuthenRequest using Scoping with an IDPList 
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_123456789097da188e1e4016be09fb13c422553cea" Version="2.0"
    IssueInstant="2015-02-25T14:13:02Z"
    Destination="https://engine.surfconext.nl/authentication/idp/single-sign-on"
    AssertionConsumerServiceURL="https://profile.surfconext.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
    <saml:Issuer>https://profile.surfconext.nl/simplesaml/module.php/saml/sp/metadata.php/default-sp</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
    <samlp:Scoping>
        <samlp:IDPList>
            <samlp:IDPEntry ProviderID="https://idp.surfnet.nl"/>
            <samlp:IDPEntry ProviderID="http://authentigate.surfmarket.nl/adfs/services/trust"/>
        </samlp:IDPList>
    </samlp:Scoping>   
</samlp:AuthnRequest>

 

Dutch scoping

When a SP cannot support scoping, also the "transparent metadata" at https://engine.surfconext.nl/authentication/proxy/idps-metadata 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).

  • No labels