8. NZ SAMS Constraints on OASIS SAML v2.0 Conformance Requirements

Table 6 - NZ SAMS constraints on OASIS SAML v2.0 conformance requirements

Section Description

SubSection

Line

What is excluded or altered from the SAML v2.0 Conformance Requirements Specification

Feature Matrix

3.2

Table 2

182 - 183

The following features are REQUIRED:

• Web SSO, <AuthnRequest>, HTTP Redirect
• Web SSO, <Response>, HTTP POST
• Web SSO, <Response>, HTTP Artifact
• Artifact Resolution, SOAP
• Single Logout, (IDP & SP-initiated), HTTP redirect
• Single Logout, (IDP & SP-initiated), SOAP.

The following features are NOT RECOMMENDED:

• Enhanced Client/Proxy SSO
• PAOS
• Name Identifier Management, (HTTP redirect and SOAP, both IDP and SP-initiated)*
• Identity Provider Discovery (cookie).

(Name Identifier Management is not in the initial release of this Standard because deleting or changing service users' federated identifiers from the system, adding and deleting user federated identifiers/logon tags from a SAML entity (for example the GLS) will not be in control of the service user, will not be done with SAML, but will be done by some yet to be agreed out of band process probably based on current agency implementations.)

3.2

Table 3

187 - 188

The following features are REQUIRED:

• Identity Provider Proxy
• Name Identifier Mapping, SOAP.

Implementation of SAML - Defined Identifiers

3.3

199 - 204

NZ SAMS prescribes the use of "Basic" as the Attribute Name format identifier (section 8.2.3, Assertions and Protocols - a.k.a SAMLCore) and "Persistent" as the Name Identifier format identifier (section 8.3.7, Assertions and Protocols - a.k.a SAMLCore). Ignore the other Name identifier format identifiers in Section 8.3 unless otherwise specified here since NZ SAMS is not prescribing the use of Name Identifier Management.

3.3

193

Deployment guidance: In relation to the All-of-government Authentication Programme, during normal logon messaging exchanges between an agency SP and the GLS IdP, the GLS does NOT return any attributes (i.e. in <AttributeStatement> elements of the SSO Assertion). In the case of the proposed IVS, the attributes are not exchanged as part of the web SSO in SAML terms. They are exchanged through the use of the AttributeQuery/SOAP exchange to an Attribute Authority.

In relation to other intra-sector agency messaging exchange, SAML identity attributes MAY be exchanged. Support for the following SAML Attribute Name Identifier Formats is REQUIRED: urn:...:attrname-format:basic

Additional Attribute Name Identifier Formats are NOT REQUIRED.

3.3

194

Deployment guidance: In relation to the All-of-government Authentication Programme, while the federated logon tag conforms to SAML persistent identifier construction rules AND the while the system and use cases ONLY use federated identifiers to identify service users, then NZ SAMS will NOT REQUIRE support for additional SAML Name Identifier Formats listed here and in sections 8.2 and 8.3 of SAMLCore except:

• Persistent Identifier in 8.3.7: urn:...:nameid-format:persistent
• For system entities, the format "urn:...:nameid-format:entity" is REQUIRED by SAML.

Section 8.3.6, line 3316 of SAMLCore indicates that it is "RECOMMENDED" that system entities use URLs containing their own domain name as their identifier. The NZ SAMS Standard makes this REQUIRED (see also the NZ SAMS metadata profile in section 9 of this Standard).

Implementation of Encrypted Elements

3.4

215 - 220

Deployment guidance: This section is implementation-dependent and subject to the agreement of the exchanging parties. If the message does not carry any personally-identifiable information in the assertions (e.g. the service user's name or unencrypted identity attributes), then encrypting the assertion, might put unnecessary overhead on the message structure and adversely affect performance of the application. The pseudo-randomness construction of the persistent (federated) identifiers should create satisfactory integrity in many instances. Even if the SSL encryption (the assertions at either end beyond the end of the SSL channels) were compromised, those ID's cannot be traced back to the local identity on either side. If the message was passing attribute data, the individual attributes could be encrypted instead of the whole assertion. However, if several individual elements within an assertion require individual encryption, it may be more "performance-efficient" to encrypt the whole assertion instead. Each element that gets encrypted might cause creation of its own symmetric encryption key, each of which gets encrypted in the target's public key. Encrypting the whole assertion would do that only once.

Security Models for SOAP and URI Bindings

3.5

221 - 231

As indicated by the exclusion of the Table 4 Operational Modes, NZ SAMS will not require the URI binding.

When using the SOAP binding between NZ SAMS entities, the following authentication methods MUST be supported for NZ SAMS compliance:

• HTTP basic authentication with SSL 3.0 or TLS 1.0
• HTTP over SSL 3.0 or TLS 1.0 server authentication with server-side certificate
• HTTP over SSL 3.0 or TLS 1.0 mutual authentication with both server-side and client-side certificates.

Additional authentication methods SHOULD NOT be used.

Deployment guidance: The above authentication methods are channel-based. In use cases involving the Artifact Resolution Profile, (which uses the SOAP back channel), the IdP and SP entities MUST authenticate each other for security reasons. End "entity" client certificates are quite often used for this. These client certificates could be used for mutual SSL authentication or to digitally sign the <ArtifactResolve> message, and the certificate validating the signature authenticates the sender.

XML Digital Signature and XML Encryption

4.1 XML Signature Algorithms

232 - 248

The algorithms listed as being required for SAML v2.0 conformance are based on the mandated algorithms in the W3C recommendations for XML Signature and for XML Encryption, but modified by the OASIS Security Services Technical Committee (SSTC) developing SAML v2.0 to ensure interoperability of conformant SAML implementations. While the SAML-defined set of algorithms is a minimal set for conformance, additional algorithms supported by XML Signature and XML Encryption MAY be used.

Deployment guidance: The use of non-mandated algorithms may introduce interoperability issues if those algorithms are not widely implemented in New Zealand government agencies. As additional algorithms become mandated for use in XML Signature and XML Encryption, the set required for SAML conformance may be extended.

To assist implementers in longer term planning, the following are referenced from NZSIT400 section 3.9.16 Message & certificate signature algorithms and section 3.9.17 Hashing Algorithms. (Refer also to SAML2Meta Section 3, Signature Processing):

• Digital Signature Algorithm (DSA) - MAY be used, but SHOULD be phased out in favour of EC DSA. See below. Modulus MUST be at least 1024 bits.
• The Elliptic Curve Digital Signature Algorithm (EC DSA) is preferred. The field/key size MUST be at least 256 bits. (However, there are no known SAML implementations that have undertaken interoperability testing with this algorithm)
• Rivest-Shamir-Adleman (RSA) - MAY be used, SHOULD be phased out. Modulus MUST be at least 1024 bits.
• El-Gamal - MAY be used, SHOULD be phased out. Field size MUST be prime and at least 1024 bits.
• Secure Hashing Algorithm (SHA). The digest MUST be at least 256 bits.

4.2

XML Encryption Algorithms

Deployment guidance:

To assist implementers in longer term planning, the following are referenced from NZSIT400 section 3.9.18 Symmetric encryption algorithms.

• Advanced Encryption Standard (AES) is the preferred algorithm. AES supports key lengths of 128, 192 and 256 bits, all of which are suitable.
• Triple DES (3DES) - SHOULD be phased out. MUST use either 2 or 3 distinct keys.

Section 5 Use of SSL 3.0 or TLS 1.0

Deployment guidance: The set up algorithms required for SAML v2.0 conformance is equivalent to those defined in SAML v1.0 and SAML v1.1. These mandated algorithms were chosen by the OASIS SSTC because of their wide implementation support in the industry. While the algorithms defined below are the minimal set for SAML conformance, additional algorithms supported by SSL 3.0 and TLS 1.0 MAY be used.

Refer also to NZSIT400 Part 3.