Appendix B - OASIS SAML v2.0 Profiles and Bindings Selection
B1 Selection criteria principles
The purpose of showing the selection criteria principles here is to indicate to readers the basis on which the applicable OASIS SAML v2.0 Profiles and Bindings were selected.
This subsection is informative and may be omitted from the final release of this Standard.
The OASIS SAML v2.0 profiles and their constituent subparts selected for refinement in the New Zealand government environment are based on the following criteria:
- Harmonised service user experience (Example 1: Service user goes to target website first before being redirected to authenticate – suggests New Zealand government adopts only SP-initiated profiles. Example 2: Experience the same with any reasonably modern browser).
- Positive end user experience (Example 1: Bandwidth efficiency – Prioritising profiles that do not take up substantial bandwidth thereby causing a slower response than alternatives. Example 2: Latency and time delay due to processing-related efficiencies).
- Consistent with Enterprise Architecture principles, and planned/existing centralised architectures such as the Government Shared Network (GSN) and the Government Logon Services (GLS).
- Evidence-based – support well-documented usage patterns (as evidenced by agency use cases so far, such as SSO, SLO etc).
- Risk management-based based on the risk-assessment process used to determine evidence of identity (EOI) and on-going confirmation of identity requirements.
- Authentication message channel (e.g. Internet Protocol and not Mobile or Smart Card).
- Current and emerging New Zealand security standards (e-GIF/SIGS/NZSIT).
- Widespread support from vendors (Example 1: Vendor support of and compliance with SAML Operational Modes and negotiating the encryption and digital signature algorithms identified in the OASIS Conformance Requirements Specification SAML Conf, found at: http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
- Vendor Implementability – ease of implementation for agencies through vendor product compliance with and successful interoperability testing derived from the following:
- the OASIS Conformance Requirements Specification found at:
http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf- the Liberty ID-FF 1.2 Interoperability conformance testing procedures found at: http://www.projectliberty.org/activities/conformance/iop procedures idff-1.2-v062.pdf
- The Liberty Alliance SAML v2.0 Test Procedures Document, Draft v03 found at:
http://www.projectliberty.org/scripts/LAP-SAMLv2_0-TestProcs-v03.pdf
B2 SAML v2.0 Specifications and profiles for constraint into the NZ SAMS standard for Release 1.0 – authentication assertion messages
Table B1 below shows the SAML v2.0 Specifications and Profiles selected for constraint in this release of NZ SAMS and the rationale for their inclusion/exclusion.
Table B1 – SAML v2.0 Specifications and profiles for constraint into NZ SAMS for Release 1.0 – authentication
|
SAML v2.0 Specification or Profile |
Rationale & Criteria used for Inclusion |
Comments |
|
SAML v2.0 Conformance Requirements (and Liberty Interoperability conformance and SAML V2.0 testing documentation where applicable) |
Vendor support Implementability |
Notation will also refer reader to the Security & Privacy Considerations paper. |
|
SAML Metadata Profile |
Vendor support Implementability |
The actual publication and resolution of metadata will be informed by the New Zealand Government Object Repository project. |
|
Web Browser SSO Profile IdP Proxy (variant SSO Profile) |
Harmonised user experience Agency use case |
Prioritise the Service Provider (SP) initiated bindings: HTTP Redirect (request) > HTTP Post (response) HTTP Redirect (request/response) >HTTP Artifact (request/response via a back channel). Uses bindings shown above, but it has NOT been published in the SAML v2.0 Profile specification. |
|
SSO Profile – Single Log Out |
Harmonised user experience Agency use case |
Expected to be utilised when service user is logged into multiple sites to potentially engage in some “joined-up” service. Optional SOAP binding in addition to other HTTP transports. |
|
Artifact Resolution Profile |
Harmonised user experience Agency use case |
This profile is the primary means of transporting assertions between the GLS and SPs via a back channel. |
|
Assertion Query/Request Profile |
Needed for Interoperability |
Uses SOAP binding. |
|
SSO Profile – Name Identifier Mapping |
Arose from an agency use case where the service user needs to authenticate with the GLS, and use the IVS as an Attribute Authority in one session |
Uses SOAP binding. |
B3 SAML v2.0 Specifications and profiles for constraint into the NZ SAMS standard for subsequent releases
Subsequent releases will refine for New Zealand government use the remaining applicable parts of the SAML v2.0 Specifications. For completeness, the remaining Profiles and Specifications not selected for this release of NZ SAMS constraint are listed below in Table B2 in order of priority.
Table B2 – SAML v2.0 Specifications and profiles for constraint into NZ SAMS for subsequent releases
|
SAML V2.0 Specification or Profile |
Rationale & Criteria used for Inclusion |
Comments |
|
IdP-centric web Single Sign On (SSO) |
Agency use case where SP-initiated unable to be used. Possibly needed for ESAA where legacy applications are involved. |
IdP-initiated, where service user logs into the IdP first rather than the SP first and subsequently redirected. Optional SOAP binding in addition to other HTTP transports. |
|
SSO Profile - Name Identifier Management Profile |
Future agency use cases showing more IdP roles beyond the current three. |
Not expected to be used in 2006/7. |
|
SSO Profile - IdP Discovery |
Future agency use cases showing more IdP roles beyond the current three. |
Cookie setter and cookie getter using HTTP binding. Not needed until there is a significant number of IdPs. |
|
Enhanced Client Proxy (ECP) |
Future agency use cases. A possible solution for ESAA where legacy applications are involved. |
User accesses SP via some device e.g. a mobile or PDA, that does not have HTTP capability and requires authentication. ECP can also be used in non-web facing applications. |
|
SSO Profile – SAML Attribute Profiles (X500LDAP, UUID, DCE PAC, XACML) |
Future agency use cases. |
Little vendor support to date. |
|
SAML token profile for Web Services Security (WSS) SOAP Message Security V1.1 |
Future agency use cases WSS Addressing endorsed by W3C and vendors. |
Profiles relating to SAML over Web Services are to be refined after Browser based profiles are complete. |
|
Authentication Query |
Future agency use cases. |
Uses SOAP binding. |
|
Authorisation Decision Query |
When detailed use case proposed by agency. |
Referred to in the ESAA RFP, 30 August 2005. Uses SOAP binding. |