You are here: Home » Standards » Interoperability (e-GIF) » Authentication Standards » New Zealand Security Assertion Messaging Standard » 12. NZ SAMS Constraints on the OASIS SAML v2.0 Core (Assertions and Protocols)

12. NZ SAMS Constraints on the OASIS SAML v2.0 Core (Assertions and Protocols)

[ Table of Contents ]

Specification Name: Assertions and Protocols for OASIS SAML v2.0

SAML Specification Reference: Saml-core-2.0-os

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

Assertions and Protocols support the Web SSO Bindings (section 11 of NZ SAMS). A complete prescription is not provided here. [SAMLCore] (Assertions and Protocols) Specification is largely prescriptive in any case. Particular attention is drawn to the following areas for NZ SAMS compliance:

Name Identifier Management protocol (section 3.6) is NOT REQUIRED.
Attribute Name Format Identifiers (section 8.2):
urn:oasis:names:tc:SAML:2.0:attrname-format:basic only is REQUIRED.
Remaining Attribute Name Format Identifiers (i.e. urn:oasis:names:tc:SAML:2.0:attrname-format:uri) are NOT REQUIRED.
Name Identifier Format Identifiers (section 8.3):
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent is REQUIRED.
Remaining Name Identifier Format Identifiers (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName and urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos) are NOT REQUIRED.
The Status element in the response MUST be utilised to convey the status (i.e. success, error conditions) of the corresponding request.

^{End of line 834}

The following table, Table 10 describes the selected requirements from OASIS v2.0 core (Assertions and Protocols).

Table 10 – NZ SAMS constraints on the OASIS SAML v2.0 core (Assertions and Protocols)

Section 2: SAML Assertions

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

Subsection 2.5.1.5: Element <OneTimeUse>

Line: 940-971

If the POST profile is used to return a signed SAML assertion then <OneTimeUse> MUST be specified. This attribute prevents the possibility of replay attacks. This MUST be tested for NZ SAMS compliance.

Section 3: SAML Protocols

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

Subsection 3.2.2: Complex Type StatusResponseType

Line: 1536-1723

The <Status> element in the response SHOULD be utilised to convey status of the corresponding request. Custom second-level <StatusCode> elements MAY be used. Third level <StatusCode> elements MUST NOT be used.

Deployment alignment:
If an <AuthnRequest> was successful then a first-level <StatusCode> of 'uri...Success' MUST be used. When a 'business rule' error has occurred (application specific exception handling i.e. 'The user has cancelled their logon') then a first-level status code of 'Requester' MUST be used in conjunction with a custom agreed second-level status code. All other pre-defined status codes are for SAML system behaviour, i.e. invalid SAML message.

It is RECOMMENDED that the <Status> element be used to communicate the status of the SAML message, but limited support for application control of 'Status' is offered by existing SAML v2.0 vendor products. Some SAML IdP products do not allow application control of the <Status> element, as it is only used to convey SAML parsing or validation errors. A similar problem occurs for SPs, where a client application cannot access the returned <StatusCode> to determine why the SAML exchange has failed. A potential solution (until support for <StatusCode> becomes more available), but NOT RECOMMENDED, is to use the <Status>. See page 63 for information on <errorURL>.

^{End of line 859}

Subsection 3.4.1 Element AuthnRequest

Line: 2001-2323

If a <RequestedAuthnContext> element is included in the <AuthnRequest> then the Comparison attribute MAY be specified.

<AuthnContextClassDecl> MUST NOT be used.

Deployment alignment:
Custom <AuthnContextClassRef> MAY be utilised. Where custom <AuthnContextClassRef> elements are used, they MUST be communicated out of band by the IdP.

An out of band agreement MUST be established between the SP and IdP for which an SSO Binding Set is to be used, i.e. POST or Artifact. If relative authentication strengths need to be communicated then these need to be framed around the ‘NIST-800-63’ levels.

Subsection 3.6: Name Identifier Management Protocol

Line: 2411-2506

Reference to Name Identifier Management protocol is NOT REQUIRED.

^{End of line 870}

Section 8: SAML defined identifiers

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

Subsection 8.2: Attribute Name Format Identifiers:

Line: 3259-3274

Basic only is REQUIRED. Remaining Attribute Name Format Identifiers (URI Reference) are NOT REQUIRED.

Subsection 8.3: Name Identifier Format Identifiers:

Line: 3275-3365

Persistent is REQUIRED. Remaining Name Identifier Format Identifiers (EmailAddress, X509SubjectName, WindowsDomainQualifiedName and Kerberos) are NOT REQUIRED.

Deployment alignment:
Unspecified MAY be used, it is at the IdP's discretion what 'name-id-format' is returned. The Name Identifier Format Identifier returned is dependent on use case requirements.