• Created by Unknown User (urn:collab:person:surfguest.nl:d09fa6a3-58f5-48a7-aa62-17f02489c888) on Mon 05 Dec 2016

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

Compare with Current View Page History

Version 1 Next »

In the authentication process a SAML 2.0 authentication request will be sent to SURFconext.

Supported bindings

SURFconext supports two types of binding:

  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect (preferred)
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST (see saml-bindings-2.0-os.pdf)

Signing

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

There is only one signing algorithm supported:
http://www.w3.org/2000/09/xmldsig#rsa-sha1.

  • 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 retries [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

The next options can be used in the authentication request (see also Interoperable SAML 2.0 Web Browser SSO Deployment Profile):

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 [dan de beschrijving hier weglaten zou ik zeggen]. Use AssertionConsumerServiceURL instead.

If no AssertionConsumerService is specified, SURFconext will use the default form [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 form the SP metadata registered in SURFconext.

ForceAuthn

Set ForceAuthn to true to disable single sign-on. If a user had already logged in at SURFconext, this will be ignored and he will have to authenticate again at his home IP. SURFconext will pass ForceAuthn to his home IP.

 

To force a user to login again at his home IP, both the AuthnRequest from the SP to SURFconext and the resulting AuthnRequest from SURFconext to the home IP must be signed. Signing prevents a user to remove the force logon requirement by modifying the AuthnRequest. Signing is supported by SURFconext, but is disabled in the default configuration. Note that cooperation of the affected home IPs is required as well to enable validation of AuthnRequests on their end. [deze alinea begrijp ik niet helemaal]

Contact SURFconext support if you require strict adherence to the ForceAuthn parameter. [wat is dat?] They can enable verification and signing of AuthnRequest by SURFconext, and can contact the home IPs involved. 

 

IsPassive

Not supported.

NameIDPolicy

AllowCreate

The value of AllowCreate is ignored. [=not used?]

Format

You can specify a Format attribute in the NameIDPolicy element [is NameIDPolicy niet een attribute en Format een element?] of your authentication request. Whether this request is honored depends on the configuration for your SP in SURFconext. For your SP SURFconext has:

  • A default NameID format. If no format is requested in the NameIDPolicy - Format element in an AuthnRequest this is the format that will be used
  • A list of allowed NameIDFormats. If a format is requested in the NameIDPolicy - Format element and this format is in the list of allowed NameIDFormats for the SP the requested format is used. Otherwise the default format is used.

The default configuration of SURFconext for a SP is to allow a NameID format of urn:oasis:names:tc:SAML:2.0:nameid-format:transient only.

RequestedAuthnContext

This element is ignored. The authentication method is agreed upon out-of-band with the SURFnet connected institutions that provide the Identity Providers. [??]

Scoping

This element is used by a SP to restrict the IdPs available though a proxying IdP (like SURFconext).

SURFconext supports use of the RequesterID element and the IDPList element only. Other elements are not supported.

RequesterID

Use the RequesterID to restrict what IdPs are allowed to authenticate to your SP. The typical use case is a SP performing authentication on behalf of another SP (i.e. a SP proxy).

The RequesterID element must contain the EnityID of a SP. This EntityID must be registered with SURFconext but does not require to have any SAML endpoint information (e.g. AssertionConsumerService Location). It must however meet all other requirements for a SP like responsible contact, logo, name etc.

When specifying a RequesterID SURFconext will limit the allowed IdPs to the cross section of the IdPs that are allowed access to both SPs. For a SP to be able to rely in this restriction it needs to ensure that a malicious user can not circumvent the restriction by modifying the AuthnRequest. There are two ways this can be accomplished:

  1. Signing the AuthnRequest and requesting SURFconext to enable signature validation for the proxying SP. You must explicitly state this in your request to SURFconext support, as this is not the default configuration.
  2. Verifying that the IdP EntityID in the AuthenticatingAuthority element in the AuthnContext in the SAML Assertion is that of an IdP that is allowed access. For this you need to know the EntityIDs of the IdPs that are allowed access to your SP. You can get this list dynamically by requesting the SP specific metadata: https://engine.surfconext.nl/authentication/proxy/idps-metadata?sp-entity-id=<the EntityID of your SP>

IDPList

The IDPList element can be used to limit the selection of IdPs shown in the SURFconext WAYF (see also IdP Discovery - WAYF) to those listed in the IDPList. The IDPList element 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: https://engine.surfconext.nl/authentication/proxy/idps-metadata. When there would be exactly one IdP shown in the WAYF, the user is directed to the IdP immediately without being shown a WAYF.

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  Expand source

<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

An alternative way for a SP to select a specific IdP in its authentication request instead of using the SURFconext WAYF is to use the "transparent metadata" at https://engine.surfconext.nl/authentication/proxy/idps-metadata. This method relies on each IdP having a different SSO Location and is applicable when the SP cannot support Scoping. A typical usecase is a SP that provides its own WAYF or discovery service (Dutch Scoping).

  • No labels