View Source

Different bindings can be used in SAML to transport messages between parties.

The interfaces Interface specifications HM-AD and Interface specifications HM-MR MUST use Artifact-Artifact binding.

The interface Interface specifications DV-HM MUST use Artifact binding for the response. The Herkenningsmakelaar (HM) MUST offer the Artifact binding and MAY offer alternative bindings to the Dienstverlener (DV) to communicate the Authentication Request. The response will always be delivered over an Artifact-binding (i.e. Artifact-Artifact, Redirect-Artifact or Post-Artifact).

The interface Interface specifications HM-EB MUST use Artifact-Artifact binding.

HTTP Artifact

The SAML V2.0 defined artifact type of type code 0x0004, as described in paragraph §3.6.4 of the SAML Bindings 2.0 document MUST be used. Note that the artifact resolution endpoint is a web service as described under Web services. Furthermore, an artifact MUST be provided only once, as per §3.6.5.2 of SAML Bindings 2.0.

The <Status> element of an ArtifactResponse MUST always include a <StatusCode> element with the code value 'urn:oasis:names:tc:SAML:2.0:status:Success', in accordance with SAML Binding §3.6.6.

In case an Artifact cannot be provided, an error MUST be returned in the Status element of the response child element of the ArtifactResponse. A generic Response (SAML ResponseType) element MAY be used to hold that status.The status reported in the response child element's Status MUST be in accordance with Error handling.

SAML Bindings 2.0 §3.6.4 recommends filling the artifact's SourceID in artifacts by taking the SHA-1 hash of the issuer (= EntityID). In all parties MUST apply this recommended method to define and resolve the SourceID in artifacts.

SAML Bindings 2.0 §3.6.3 specifies that artifact can be encoded as either HTTP GET or HTTP POST request and both techniques MUST be supported.

ArtifactResolve

@ID	SAML: Unique message characteristic. MUST identify the message uniquely within the scope of the sender and receiver for a period of at least 12 months.
@Version	SAML: Version of the SAML protocol. The value MUST be '2.0'.
@IssueInstant	SAML: Time at which the message was created.
@Destination	: MUST NOT be included.
@Consent	: MAY be included. When Consent is included, the default value MUST contain urn:oasis:names:tc:SAML:2.0:consent:unspecified.
Issuer	: MUST contain the EntityID of the sender. The attributes NameQualifier, SPNameQualifier, Format and SPProviderID MUST NOT be included.
Signature	: MUST contain the Digital signature of the sender for the enveloped message.
Extensions	: MUST NOT be included.
Artifact	SAML: Contains the Artifact that was received as query parameter.

ArtifactResponse

@ID	SAML: Unique message characteristic. MUST identify the message uniquely within the scope of the sender and receiver for a period of at least 12 months.
@InResponseTo	SAML: Unique characteristic of the AuthnRequest for which this Response message is the answer.
@Version	SAML: Version of the SAML protocol. The value MUST be '2.0'.
@IssueInstant	SAML: Time at which the message was created.
@Destination	: MUST NOT be included
@Consent	: MAY be included. When Consent is included, the default value MUST contain urn:oasis:names:tc:SAML:2.0:consent:unspecified.
Issuer	: MUST contain the EntityID of the receiver. The attributes NameQualifier, SPNameQualifier, Format and SPProviderID MUST NOT be included.
Signature	: MUST contain the Digital signature of the sender for the enveloped message.
Extensions	: MUST NOT be included.
Status	The <Status> element MUST include a <StatusCode> element with the code value 'urn:oasis:names:tc:SAML:2.0:status:Success', if the response is valid and the artifact can be resolved. Otherwise, an error MUST be returned in accordance with Error handling.
any ##any	MUST contain a Response message if the responder recognizes the artifact as valid, otherwise contains no additional elements. The Response message MAY contain a Signature (even though it's integrity is already guaranteed by the signature on the artifact response)

SAML SOAP binding

For back-channel requests without user interaction, the SAML SOAP binding can be prescribed. The following apply in this case:

the communication MUST use a mutual authenticated Secure connection. This MUST be established using TLS with certificates as listed in the Network metadata or the DV metadata for HM.
the SAML v 2.0 SOAP binding as described in paragraph 3.2 of the SAML Bindings 2.0 document MUST be used.
as SOAPAction, the value 'http://www.oasis-open.org/committees/security' MUST be used.
The following HTTP headers MUST be set:
- Cache-Control = "no-cache, no-store"
- Pragma = "no-cache"

Alternative bindings to communicate the Authnrequest to the Herkenningsmakelaar

HTTP Post

The implementation of a HTTP Post binding MUST meet the following requirements:

The AuthnRequest MUST be signed, using a digitial signature (<ds:Signature>) as described in Digital signature.
The message MUST be encoded as a parameter 'SAMLRequest' in a HTML form using base64 encoding to be submitted via HTTP POST.
A RelayState MAY be used, it MUST be encoded as a parameter 'RelayState'.
Client-side scripting SHOULD be used to submit the form, but MUST NOT be required; the user MUST be able to submit the form manually.

HTTP Redirect

The implementation of the HTTP Redirect binding MUSTmeet the following requirements:

The AuthnRequest message MUST NOT contain a <ds:Signature> element.
The message MUST be compressed using the DEFLATE method and in turn represented in Base-64 encoding.
The compressed and coded message MUST be added to the URL as a query string parameter and MUST be designated as SAMLRequest.
If RelayState data is included in the HTTP Redirect message, it must be encoded separately and added to the URL as a query string parameter and MUST be designated as RelayState. If a RelayState is not provided, the whole parameter MUST be absent in the URL.
A digital signature MUST be calculated over the part of the URL SAMLRequest=value&RelayState=value. This digital signature MUST be generated as described in Digital signature. The digital signature MUST be included as a query string parameter. This parameter is designated as Signature.