This page describes the properties of SAML Responses and Assertions that SURFconext sends to your SP. 

A SAML response is a reaction of the IdP to SURFconext with the message that the user has been successfully authenticated (or not).
A SAML Assertion is some statements done by IdP or SP: authentication, authorization and attributes.

Your SP must be able to handle SAML Responses according to the Interoperable SAML 2.0 Web Browser SSO Deployment Profile.

Signing

SURFconext signs the Assertion element in the SAML Response. The Response element is not signed (signing of the entire response can be enabled for an SP by special request).

The signature algorithm used is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. The key used to sign the Assertion is included as X509 certificate.

Encryption

SURFconext does not support encrypting the Response or parts of it.

Binding

SURFconext supports the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST binding for sending the SAML Response to your SP. Other bindings are not supported.

The SAML Assertion

A SAML Assertion has 6 elements: Issuer, Subject, Conditions, AuthnStatement, AuthnContext and AttributeStatement.

Issuer

Issuer is set to the EntityID of the IdP according to the SURFconext metadata used:

Subject

The NameID for the Subject that was authenticated. The following formats are supported:

  • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (specific use cases only, not commonly used)

Conditions

With conditions you can limit the use of the SAML Assertion. SURFconext uses: NotBeforeNotOnOrAfter and AudienceRestriction.

Condition generated by SURFconext for a SP with EntityID "https://teams.surfconext.nl/shibboleth"
 <saml:Conditions NotBefore="2014-10-22T15:00:03Z" NotOnOrAfter="2014-10-22T15:05:03Z">
    <saml:AudienceRestriction>
        <saml:Audience>https://teams.surfconext.nl/shibboleth</saml:Audience>
    </saml:AudienceRestriction>
</saml:Conditions>

NotBefore and NotOnOrAfter

The NotBefore and NotOnOrAfter attributes are set to specify that an Assertion is valid for 5 minutes from the moment of issuance.

AudienceRestriction

Contains an Audience element that restricts the audience to your SP. The Audience element is set to the EntityID of your SP.

AuthnStatement

AuthnInstantSessionNotOnOrAfter and SessionIndex are provided by the home IdP of the user (the AuthenticationAuthority). This behaviour is subject to change.

AuthnContext

AuthenticatingAuthority

The AuthenticatingAuthority element contains the EntityID if the IdP that performed the authentication of the user. This EntityID will be listed in the IdPs metadata of SURFconext: https://metadata.surfconext.nl/idps-metadata.xml

AuthnContextClassRef

When stepup authentication with SURFsecureID has been performed, this will list the attained Level of Assurance (e.g. 'http://surfconext.nl/assurance/loa3'). If not, this will be the AuthnContextClassRef that the Identity Provider specified.

AttributeStatement

The AttributeStatement element contains attributes for the Subject like displayName, email address or entitlement.

What attributes you receive exactly depends on:

  • The attributes the IdP of the user can provide
  • The attribute filter (ARP) set for your SP.

In case your SP software is sensitive to the nameformat used (like e.g. Shibboleth): the NameFormat of the attributes is urn:oasis:names:tc:SAML:2.0:attrname-format:uri. 

By default SURFconext includes both the named and the oid (Object Identifier) version of each attribute. E.g. for the displayname attribute both "urn:mace:dir:attribute-def:displayName" and "urn:oid:2.16.840.1.113730.3.1.241" will be included (more info about Attribute Schemas). If there should be only one version for your SP: contact SURFconext support to disable this.

The OID and URN registries lend structural support to trust, identity and middleware applications by providing common definitions, assignment mechanisms and consistent guidelines and implementation practices.


Below an example of an attribute as your SP may receive it for SURFconext. An Attribute may contain multiple AttributeValue elements.

givenName Attribute
<saml:Attribute Name="urn:mace:dir:attribute-def:givenName"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue>Pieter</saml:AttributeValue>
</saml:Attribute>


The edupersonTargetedID attribute contains the same NameID as is present in the Subject of the Assertion. Note that the AttributValue contains a NameID element instead of a simple value:

edupersonTargetedID
<saml:Attribute Name="urn:mace:dir:attribute-def:eduPersonTargetedID"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue>
        <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">c693b1c47a0da7de6518bc30a1bb8d2e44b56980</saml:NameID>
    </saml:AttributeValue>
</saml:Attribute>

Navigate



  • No labels