Specification Name: Conformance Requirements for OASIS SAML v2.0
SAML Specification Reference:Saml-conformance-2.0-os
This html page contains lines 1-153 from Part 2 of the PDF version of NZ SAMS v1.0
The SAML v2.0 Conformance Specification [SAMLConf] defines a set of roles to which SAML implementations and vendor products may claim they conform. The Specification also includes several sections that specify additional requirements that apply to all Operational Modes and uses of SAML v2.0.
Table 1 of the Conformance Specification provides a description of the foreseen deployments of SAML message flows for the various SAML-defined profiles when combined with the supported SAML bindings. This table is for informational purposes only.
The columns of tables 2, 3 and 4 of the Conformance Specification define the normative SAML Operational Modes by listing the conformance-related SAML features and identifying the SAML messages used by each feature along with the SAML bindings that may be used to carry those messages. Each Operational Mode then identifies whether or not each item in the list must be supported for that mode.
The NZ SAMS requirements (derived from the use cases in Appendix A), mapped to Table 2 of the Conformance Specification, are listed in Table 6 of this Standard. The NZ SAMS requirements mapped to Table 3 of the Conformance Specification, allow ii supportof the following SAML Operational Modes:
IdP Proxy
Name Identifier Mapping, SOAP.
The IDP Extended and SP Extended modes are defined in Table 3 of the Conformance Specification.These modes presume the presence of all IdP and SP mode features as described in Table 2 of the Conformance Specification.
Table 4 of the Conformance Specification defines the SAML Authority and Requestor OperationalModes. NZ SAMS requires the use of the SAML Attribute Authority Operational Mode for certaininteractions where two SPs are involved in one authentication session (see the usage pattern in NZ SAMS 6.2.3 'SP initiated with Name Identifier Mapping').
The SAML Operational Modes mandate certain features that are not specifically required by NZSAMS, though SAML implementations that claim conformance to these Operational Modes mightneed to support those features. The following table, Table 6 further refines the required modes foruse by NZ SAMS.
End of line 29
Table 6 – NZ SAMS constraints on OASIS SAML v2.0 conformance requirements
The list below details exclusions or alterations from the SAML v2.0 Conformance Requirements Specification sections:
Feature Matrix
Implementation of SAML – Defined Identifiers
Implementation of Encrypted Elements
Security Models for SOAP and URI Bindings
XML Digital Signature and XML Encryption
XML Encryption Algorithms
Use of SSL 3.0 or TLS 1.0
Feature Matrix
Subsection: 3.2 Table 2 Line: 182 – 183 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:
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 and SP-initiated), HTTP redirect
Single Logout, (IdP and 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). See note.
Identity Provider Discovery (cookie).
Note:(Name Identifier Management is not in the initial release of this Standard because deleting or changing service users' federated identifiers from the system, and also 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. This 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.) Subsection: 3.2 Table 2 Line: 187 – 188 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:The following features are OPTIONAL:
Identity Provider Proxy
Name Identifier Mapping, SOAP.
End of line 51
Implementation of SAML – Defined Identifiers
Subsection: 3.3 Line: 199 – 204 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification: NZ SAMS prescribes the use of 'Basic' as the Attribute Name Format Identifier (section 8.2.3, Assertions and Protocols [SAMLCore]) and 'Persistent' as the Name Identifier Format Identifier (section 8.3.7, Assertions and Protocols [SAMLCore]). If a Name Identifier Format Identifier of 'Unspecified' is obtained then the IdP will return a Name Identifier Format Identifier as per the use case requirement. Ignore the other Name Identifier Format Identifiers in section 8.3 [SAMLCore] unless otherwise specified here since NZ SAMS is not prescribing the use of Name Identifier Management. Subsection: 3.3 Line: 193 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification
:
Deployment alignment
In relation to the All-of-government Authentication Programme, in the case of the proposed IVS, the attributes are exchanged as part of the SAML assertion. The attributes will be contained within the <AttributeStatement> within the SAML response. See Appendix D for in-depth details. Support for the following SAML Attribute Name Identifier Formats is REQUIRED: urn:oasis:names:tc:SAML:2.0:attrname-format:basicIn relation to other intra-sector agency messaging exchange, SAML identity attributesMAY be exchanged. Additional Attribute Name Identifier Formats are NOT REQUIRED.
Subsection: 3.3 Line: 194 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:
Deployment alignment
In relation to the All-of-government Authentication Programme, while the federatedlogon tag conforms to SAML persistent identifier construction rules AND while thesystem and use cases ONLY use federated identifiers to identify service users, then NZSAMS will NOT REQUIRE support for additional SAML Name Identifier Formatslisted here and in sections 8.2 and 8.3 of [SAMLCore] except:
Persistent Identifier in 8.3.7: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
Unspecified Identifier in 8.3.1: urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified. When an ‘unspecified’ identifier is received at an IdP, anidentifier MUST be returned as per use case requirements.
For system entities, the format 'urn:oasis:names:tc:SAML:2.0:nameid-format:entity' is REQUIRED by SAML.
End of line 79 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. NZ SAMS makes this REQUIRED (see also the NZ SAMS metadata profile in section 9 of NZ SAMS).
Implementation of Encrypted Elements
Subsection: 3.4 Line: 215 – 220 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification
:
Deployment alignment
This section is implementation-dependent and subject to the agreement of the exchanging parties. When using the HTTP POST binding encryption of the assertion MUST occur. See 6.3.4 'Encryption and digital signature considerations' for detailed information. 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-random 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 IDs 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. But this is not desirable as MITM (man-in-the-middle) attacks can intercept potentially sensitive data, e.g. <NameID>. For this reasonencryption of the entire assertion MUST occur when using the POST profile. Encryptionof the assertion will also ensure encryption of the Name Identifier.
End of line 99
Security Models for SOAP and URI Bindings
Subsection: 3.5 Line: 221 – 231 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:As indicated by the exclusion of the Table 4 Operational Modes, NZ SAMS will notrequire the URI binding.When using the SOAP binding between NZ SAMS entities, the following authenticationmethods 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 andclient-side certificates.
Additional authentication methods SHOULD NOT be used.
Deployment alignment
The SP MUST have an SSL certificate and in most implementations a signing certificate(see section 6.4 of NZ SAMS). These certificates MUST be issued by a trustedcertificate authority. Note that while SSL certificates are used, they are not conveyed inthe metadata. Instead the SSL protocol handshake will send the certificate as needed.
Trust in SSL certificates is typically via PKI (i.e. trusted Certificate Authority). NeitherSP nor IdP needs to have an encryption/client TLS certificate, but if they have one itMAY be present in the metadata.
XML Digital Signature and XML Encryption
Subsection: 4.1 XML Signature Algorithms Line: 232 – 248 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:The algorithms listed as being required for SAML v2.0 conformance are based onthe mandated algorithms in the W3C recommendations for XML Signature and forXML Encryption, but modified by the OASIS SSTC developing SAML v2.0 to ensureinteroperability of conformant SAML implementations. While the SAML-defined set ofalgorithms is a minimal set for conformance, additional algorithms supported by XMLSignature and XML Encryption MAY be used. While requirements detailed in sections4 and 5 [SAMLConf] define a minimal set of algorithms, additional algorithms MAYbe accepted. However additional algorithms SHOULD NOT be used unless there is anagreement between parties about their use.
Deployment alignment
The use of non-mandated algorithms may introduce interoperability issues if thosealgorithms are not widely implemented in New Zealand government agencies.As additional algorithms become mandated for use in XML Signature and XMLEncryption, the set required for SAML conformance may be extended.
End of line 128To assist implementers in longer term planning, the following are referenced from[NZSIT402] section 2.9.16 'Message and certificate signature algorithms' and section2.9.17 'Hashing algorithms'. (Refer also to [SAMLMeta] Section 3, 'SignatureProcessing'):
Digital Signature Algorithm (DSA) – MAY be used, but SHOULD be phased out infavour of EC DSA. See below. Modulus MUST be at least 1024 bits.
The Elliptic Curve Digital Signature Algorithm (EC DSA) is preferred. Thefield/key size MUST be at least 256 bits. (However, there are no known SAMLimplementations that have undertaken interoperability testing with this algorithm.)
Rivest-Shamir-Adleman (RSA) – MAY be used, SHOULD be phased out. ModulusMUST be at least 1024 bits.
El-Gamal – MAY be used, SHOULD be phased out. Field size MUST be prime andat least 1024 bits.
Secure Hashing Algorithm (SHA). The digest MUST be at least 256 bits.
XML Encryption Algorithms
] Subsection: 4.2 XML Encryption Algorithms What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification:
Deployment alignment
To assist implementers in longer term planning, the following are referenced from[NZSIT402] section 2.9.18 'Symmetric encryption algorithms'.
Advanced Encryption Standard (AES) is the preferred algorithm. AES supports keylengths of 128, 192 and 256 bits, all of which are suitable.
Triple DES (3DES) – SHOULD be phased out. MUST use either 2 or 3 distinctkeys.
Use of SSL 3.0 or TLS 1.0
Subsection: Section 5 Use of SSL 3.0 or TLS 1.0 What is Excluded or Altered from the SAML v2.0 Conformance Requirements Specification
:
Deployment alignment
The set up algorithms required for SAML v2.0 conformance are equivalent to thosedefined in SAML v1.0 and SAML v1.1. These mandated algorithms were chosen bythe OASIS SSTC because of their wide implementation support in the industry. Whilethe algorithms defined below are the minimal set for SAML conformance, additional algorithms supported by SSL 3.0 and TLS 1.0 MAY be used.
End of line 153 Refer also to [NZSIT402] Part 2.
Footnotes
[ii Support will be required where the use case is derived (e.g. 'ESAA' in Appendix A1). To enable support ensure your product selection includes these features.]
This html page contains lines 1-153 from Part 2 of the PDF version of NZ SAMS v1.0