Skip to content.
|Networking government in New Zealand.
Archive

Archived articles:

See archives for this section
 
You are here: Home » Standards » Interoperability (e-GIF) » Authentication Standards » New Zealand Security Assertion Messaging Standard » 11. NZ SAMS Constraints on the OASIS SAML v2.0 Bindings

11. NZ SAMS Constraints on the OASIS SAML v2.0 Bindings

[ Table of Contents ]

Specification Name: Bindings for the OASIS SAML V2.0

SAML Specification Reference : Saml-bindings-2.0-os

This html page contains lines 663-815 from Part 2 of the PDF version of NZ SAMS v1.0

The SAML v2.0 Bindings Specification [SAMLBind] defines the allowable bindings to the communications protocols and frameworks. These bindings support the Web Browser SSO profiles in section 10.

Not all of the SAML v2.0 bindings have been prescribed for NZ SAMS which draws only on those that have been identified from agency use cases. More bindings may be added in future releases of NZ SAMS.

Section 6 of this Standard provides the background to the selection of the bindings prescribed here.

The following table, Table 9, describes the selected requirements from the OASIS SAML v2.0 bindings.

End of line 671

Table 9 - NZ SAMS constraints on the OASIS SAML v2.0 bindings

Section 2: Guidelines for specifying additional protocol bindings

What is excluded or altered from the SAML v2.0 Bindings Specification:

Line: 187 – 220

New Zealand government agencies MUST submit any additional or new protocol bindings to the Secure Messaging Working Group in the first instance. The Working Group can work through the implications of the proposal on the existing bindings in use. See the contact details in section 4 of NZ SAMS.

Section 3: Protocol Bindings

What is excluded or altered from the SAML v2.0 Bindings Specification:

Subsection 3.1 General Considerations

Section 3 describes, for each supported SAML binding, how aspects such as protocol headers, caching, error reporting, and SAML metadata should be handled. Many of these items are largely out of the control of any individual agency since they are incorporated into vendor products and implementations. All normative requirements described in these sections must be adhered to.

Deployment alignment:
For NZ SAMS compliance, in the case of error reporting (refer to lines 370-77, 826, 862 of [SAMLBind]), it is expected that errors are dealt with at the protocol level at which they occur. That is, errors that occur while establishing an SSL-secured HTTP connection (e.g. an SSL certificate problem) SHOULD return an HTTP '403 Forbidden' response. An error at a SOAP level MUST return a SOAP fault. An error while processing the internals of a SAML <Request> message SHOULD be reported by using a SAML <Response> message with an appropriate SAML status code.

End of line 687

Subsection 3.1.2.1 Security: Use of SSL v3.0 or TLS v1.0

Line: 238 –240

For NZ SAMS compliance, server identity will be achieved as proposed here, relying on mapping the certificate DN or the public key to the partner's identity.

Subsection 3.1.2.2/3 Security: Data Origin Authentication and Message Integrity

Line: 243

Deployment alignment:
'OPTIONAL' in this sentence depends on whether the message is to be transported over a secured communication channel, such as the GSN. See section 6.3.4 of NZ SAMS for more guidance.

Line: 245, 254

'MAY' in these sentences becomes 'SHOULD' for NZ SAMS compliance. The choice of bindings MUST be specified in agency exchange agreements. Deployment alignment IdP and SP applications to process the message are examples of an 'environment of use'.

Deployment alignment:
IdP and SP applications to process the message are examples of an 'environment of use'.

End of line 697

Line: 248

'recommended' in this sentence becomes 'REQUIRED' for NZ SAMS compliance.

Line: 256

'recommended' in this sentence becomes 'REQUIRED' for NZ SAMS compliance.

Subsection 3.1.2.4 Security: Message Confidentiality

Line: 260

'OPTIONAL' in this sentence depends on whether the message is to be transported over a secured communication channel, such as the GSN. See 6.3.4 of NZ SAMS for more guidance.

Deployment alignment:
Message confidentiality remains optional at a high level because certain messages, such as an artifact, contain no information that of itself is confidential.

Line: 261 – 262

Deployment alignment:
Man-in-the-middle (MITM) attacks can intercept transmitted messages. For this reason encryption MUST occur when using the POST profile. See 6.3.4 of NZ SAMS for detailed information on 'Encryption and digital signature considerations'.

End of line 707

Subsection 3.1.2.5 Security: Security Considerations

Line: 265

'SHOULD' in this line becomes 'MUST' for NZ SAMS compliance and MUST be specified in agency exchange agreements. The All-of-government Authentication Programme and IdP and SP applications to process the message are examples of a 'deployment environment'.

3.2 SAML SOAP Binding:

What is excluded or altered from the SAML v2.0 Bindings Specification:

Subsection 3.2.2 Protocol-Independent Aspects of the SAML SOAP Binding

Ignore this subsection.

Deployment alignment:
Support for SOAP headers will be controlled by the vendor products and implementations since the SOAP implementation is bundled into them.

End of line 714

Subsection 3.2.3 Use of SOAP over HTTP

Ignore this subsection.

Deployment alignment:
The SOAP header will be under the control of the SOAP library used by the vendor product or implementation. The other aspects shown here are also largely outside of the control of agencies.

Subsection 3.3 Reverse SOAP (PAOS) Binding

Deployment alignment:
This subsection will not be prescribed in the first release of NZ SAMS. It is expected to be prescribed when a usage pattern supporting the Enhanced Client Proxy profile is presented for inclusion in later releases of NZ SAMS.

End of line 721

Subsection 3.4 HTTP Redirect Binding

What is excluded or altered from the SAML v2.0 Bindings Specification:

Line: 525,529

'MAY' in these sentences MUST be specified in agency exchange agreements; that is, the use of HTTP POST or Artifact bindings in conjunction with the HTTP Redirect binding.

Subsection 3.4.3 RelayState

Line: 545 – 57

Deployment alignment:
See NZ SAMS, Table 8 entries related to 4.1.3.1, 4.1.3.5, 4.4.3.1 for further details on RelayState. Integrity protection using a checksum, a pseudo-random value or similar means may be pre-configured in many vendor products.

Subsection 3.4.4 Message Encoding

Line: 559 – 72

Deployment alignment:
Vendor products may employ methods other than metadata to indicate which encoding the binding endpoints support. Whatever method is used it needs to be one of those prescribed by SAML v2.0.

End of line 730

Subsection 3.4.4.1 DEFLATE Encoding

Line: 582

'SHOULD NOT' in this sentence becomes 'MUST NOT' for NZ SAMS compliance.

Line: 599 –615

XML signatures and the encoding mechanisms specified MUST be used for NZ SAMS compliance.

Subsection 3.4.5 Message Exchange

Line: 636 – 46

Deployment alignment:
Controlling additional information when the Redirect binding is used to carry a SAML message may not be possible in many vendor products.

Line: 645

'SHOULD' in this sentence becomes 'MUST' for NZ SAMS compliance.

End of line 736

Subsection 3.4.5.1 HTTP and Caching Considerations

Line: 652

Deployment alignment:
These rules are pre-configured in most vendor products.

Subsection 3.4.5.2 Security Considerations

Line: 659

Deployment alignment:
See 6.3.4 of NZ SAMS, 'Encryption and digital signature considerations', for further guidance on integrity protection via signatures.

Line: 668

'SHOULD' in this sentence becomes 'MUST' for NZ SAMS compliance.

Line: 673

'SHOULD' in this line becomes 'MUST' for NZ SAMS compliance and MUST be specified in agency exchange agreements. The All-of-government Authentication Programme and IdP and SP applications to process the message are examples of a 'deployment environment'.

Subsection 3.4.6 Error Reporting

Line: 679

'SHOULD' in this sentence becomes 'MUST' for NZ SAMS compliance.

End of line 745

Subsection 3.4.7 Metadata Considerations

Line: 687

'SHOULD' in this line becomes 'MUST' for NZ SAMS compliance and MUST be specified in agency exchange agreements.

Subsection 3.5: HTTP POST Binding

What is excluded or altered from the SAML v2.0 Bindings Specification:

Line: 754 – 8

'MAY' in these sentences MUST be specified in agency exchange agreements; that is, the use of HTTP Redirect or Artifact bindings in conjunction with the HTTP POST binding.

Subsection 3.5.3 RelayState

Line: 775 – 87

Deployment alignment:
See NZ SAMS, Table 8 for further details on RelayState. Integrity protection using a checksum, a pseudo-random value or similar means may be pre-configured in many vendor products

Subsection 3.5.4 Message Encoding

Line: 793

Deployment alignment:
With respect to the line wrapping value or range, the base64-encoding of the SAML message is handled by packages bundled with the vendor products and is usually not configurable. Note that no line wrapping in a message is valid.

End of line 756

Line: 803 – 6

The encoding technique MUST be specified in agency exchange agreements. The All-of-government Authentication Programme has prescribed the approach in [GLSMS].

Subsection 3.5.5 Message Exchange

Line: 821 – 2

'MAY' in this sentence MUST be specified in agency exchange agreements. The All-of-government Authentication Programme has prescribed the approach in [GLSMS].

Line: 826

The rationale for 'SHOULD' in this sentence is given above at the beginning of this section (section 3 'Protocol Bindings') for NZ SAMS compliance.

End of line 762

Subsection 3.5.5.1 HTTP and Caching Considerations

Line: 833

Deployment alignment:
These rules are pre-configured in most vendor products.

Subsection 3.5.5.2 Security Considerations

Line: 842

See 6.3.4 of NZ SAMS for further guidance on integrity protection via signatures.

Deployment alignment:
NZ SAMS rules are as for the Redirect binding. Certain messages carried via the POST binding might not really be important to sign, e.g. POST could be used for an <AuthnRequest> message (instead of a Redirect binding) and it might not need signing. Extra signatures are a significant overhead.

End of line 768

Line: 858 – 60

Deployment alignment:
SPs deploying the RelayState mechanism should note the comment on associating sensitive state values with the RelayState value. See NZ SAMS, Table 8 for further details on RelayState.

Subsection 3.5.6 Error Reporting

Line: 862

The rationale for ‘SHOULD’ in this sentence is given above at the beginning of this section (section 3 'Protocol Bindings').

Subsection 3.5.7 Metadata Considerations

Line: 870

‘SHOULD’ in this line becomes ‘MUST’ for NZ SAMS compliance and MUST be specified in agency exchange agreements.

Subsection 3.6 HTTP Artifact Binding

What is excluded or altered from the SAML v2.0 Bindings Specification:

Line: 986

‘MAY’ in this sentence MUST be specified in agency exchange agreements; that is, the use of HTTP Redirect or HTTP POST binding may be used to compose this binding.

Subsection 3.6.2 Overview

Line: 996 – 1005

Deployment alignment:
Most usage patterns that use services delivered by the All-of-government Authentication Programme are required to be supported by the HTTP Artifact binding.

End of line 780

Subsection 3.6.3 Message Encoding

Line: 1007 – 10

Deployment alignment:
Some vendor products implement the GET method and not the FORM POST method for passing the artifact (this is not the same as the POST binding), and only the GET method has been tested in certification events. The FORM POST method MUST NOT be used.

Subsection 3.6.3.1 RelayState

Line: 1012 – 25

Deployment alignment:
See NZ SAMS, Table 8 for further details on RelayState. Integrity protection using a checksum, a pseudo-random value or similar means may be pre-configured in many vendor products.

Subsection 3.6.3.2 URL Encoding

Line: 1027 – 30

Deployment alignment:
See NZ SAMS, Table 8 for further details on RelayState.

Subsection 3.6.3.3 Form Encoding

Line: 1040 – 1

'MAY' in this sentence MUST be specified in agency exchange agreements.

Subsection 3.6.4 Artifact Format

Line: 1058 –66

All practices stipulated for the creation of SAML artifacts MUST be adhered to. Certification testing is only conducted for the RECOMMENDED practices defined in [SAMLBind].

Subsection 3.6.4.2 Format Details

Line: 1082 – 3

Note that the use of the [SAMLMeta] is REQUIRED for NZ SAMS compliance.

End of line 793

Line: 1087 – 90

Deployment alignment:
The principles governing <SourceID> and MessageHandle values MUST be conducted in accordance with SAML product certification practices. Artifact creation is typically under the control of the vendor product and may not be configurable.

Subsection 3.6.5 Message Exchange

Line: 1091 –1108

An artifact/Artifact binding set MUST NOT be used.

Line: 1109 –1141

Deployment alignment:
These rules are pre-configured in most vendor products.

Subsection 3.6.5.1 HTTP and Caching Considerations

Line: 1144

Deployment alignment:
These rules are pre-configured in most vendor products.

Subsection 3.6.5.2 Security Considerations

Line: 1153, 1159

'MAY' in these sentences becomes 'MUST' for NZ SAMS compliance.

Line: 1157 – 58

'SHOULD' in this sentence MUST be specified in agency exchange agreements, since agencies using the Government Shared Network (for example) may not need additional protection of the transmission.

End of line 804

Line: 1163 – 73

Deployment alignment:
The directives in this paragraph MUST be specified in agency exchange agreements. Vendor product implementations are expected to reflect this approach but deployers are advised to check for it and provide an effective means to address this issue. The All-of-government Authentication Programme has prescribed the approach in [GLSMS].

Any deviation from 'SHOULD' in these sentences MUST be specified in agency exchange agreements.

Subsection 3.6.6 Error Reporting

Line: 1175 – 86

'SHOULD' in this sentence becomes 'MUST' for NZ SAMS compliance.

Subsection 3.6.7 Metadata Considerations

'SHOULD' and 'MAY' in these sentences become ‘MUST’ for NZ SAMS compliance and MUST be specified in agency exchange agreements.

Subsection 3.7: SAML URI Binding

Ignore this subsection. To date no use cases require the use of this very specialised binding.


This html page contains lines 663-815 from Part 2 of the PDF version of NZ SAMS v1.0


[ Previous | Contents | Next ]