8. NZ SAMS Constraints on OASIS SAML v2.0 Conformance Requirements
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 support of the following SAML Operational Modes:
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 Operational Modes. NZ SAMS requires the use of the SAML Attribute Authority Operational Mode for certain interactions 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 NZ SAMS, though SAML implementations that claim conformance to these Operational Modes might need to support those features. The following table, Table 6 further refines the required modes for use by NZ SAMS.
Table 6 – NZ SAMS constraints on OASIS SAML v2.0 conformance requirements
The table 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:
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:basic
In relation to other intra-sector agency messaging exchange, SAML identity attributes MAY 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 federated logon tag conforms to
SAML persistent identifier construction rules AND 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: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, an identifier 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.
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 reason encryption of the entire assertion MUST
occur when using the POST profile. Encryption of the
assertion will also ensure encryption of the Name Identifier.
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 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 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 trusted certificate authority. Note that while SSL certificates
are used, they are not conveyed in the 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). Neither SP nor IdP needs to have an encryption/client TLS certificate, but if they have one it MAY 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 on the mandated algorithms in the W3C recommendations for XML Signature and for XML Encryption, but modified by the OASIS 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. While requirements detailed in sections 4 and 5 [SAMLConf] define a minimal set of algorithms, additional algorithms MAY be accepted. However additional algorithms SHOULD NOT be used unless there is an agreement between parties about their use.
Deployment alignment
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 [NZSIT402] section 2.9.16 'Message and certificate signature algorithms' and section 2.9.17 'Hashing algorithms'. (Refer also to [SAMLMeta] 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.
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'.
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 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 [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
[ Previous | Contents | Next ]
