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.
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 – For example (1) a service user goes to the target website first before being redirected to authenticate; suggesting the New Zealand government adopts only SP-initiated profiles, (2) the user experience is the same with any reasonably modern browser.
- Positive end user experience – For example (1) use of bandwidth efficiency – prioritising profiles that do not take up substantial bandwidth (and therefore the response time is faster than alternatives), (2) reduction of latency and time delay via processing-related efficiencies.
- Consistent with Federated Enterprise Architecture principles, and planned/existing centralised architectures such as the Government Shared Network (GSN) and the Government Logon Services (GLS).
- Evidence-based – supports 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 identity and non-identity related risks for any online service requiring authentication.
- Choice of authentication message channel – For example Internet Protocol, and not Mobile or Smart Card.
- Current and emerging New Zealand security standards – For example [NZeGIF], [SIGS], and [NZSIT402].
- Widespread support from vendors – For example vendor support of and compliance with SAML Operational Modes; and negotiating the encryption and digital signature algorithms identified in [SAMLConf].
- Vendor Implementability – Ease of implementation for agencies through vendor product compliance with and successful interoperability testing derived from [SAMLConf], Liberty ID-FF 1.2 Interoperability Conformance Testing Procedures and The Liberty Alliance SAML v2.0 Test Procedures.
B2 SAML v2.0 specifications and profiles for constraint into NZ SAMS 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.
Table B1 – SAML v2.0 specifications and profiles for constraint into NZ SAMS for Release 1.0 – authentication
SAML v2.0 Conformance Requirements (and Liberty Interoperability conformance and SAML v2.0 testing documentation where applicable).
Rationale and Criteria used for Inclusion:
- Vendor support
- Implementability
Comments:
Notation will also refer reader to the 'Security & Privacy Considerations' paper.
SAML v2.0 Metadata Specification
Rationale and Criteria used for Inclusion:
- Vendor support
- Implementability
Comments:
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)
Rationale and Criteria used for Inclusion:
- Harmonised user experience
- Agency use case
Comments:
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
Rationale and Criteria used for Inclusion:
- Harmonised user experience
- Agency use case
Comments:
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
Rationale and Criteria used for Inclusion:
- Harmonised user experience
- Agency use case
Comments:
This profile is the primary means of transporting assertions between the GLS and SPs via a back channel.
Assertion Query/Request profile
Rationale and Criteria used for Inclusion:
- Needed for interoperability
Comments:
Uses SOAP binding.
SSO profile – Name Identifier Mapping
Rationale and Criteria used for Inclusion:
- 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
Comments:
Uses SOAP binding.
B3 SAML v2.0 specifications and profiles for constraint into NZ SAMS 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
IdP - centric Web Single Sign On (SSO)
Rationale and Criteria used for Inclusion:
- Agency use case where SP-initiated unable to be used. Possibly needed for ESAA where legacy applications are involved.
Comments:
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
Rationale and Criteria used for Inclusion:
- Future agency use cases showing more IdP roles beyond the current three.
Comments:
Not expected to be used in 2006–8.
SSO profile - IdP Discovery
Rationale and Criteria used for Inclusion:
- Future agency use cases showing more IdP roles beyond the current three.
Comments:
Cookie setter and cookie getter using HTTP binding. Not needed until there are a significant number of IdPs.
Enhanced Client Proxy (ECP)
Rationale and Criteria used for Inclusion:
- Future agency use cases. A possible solution for ESAA where legacy applications are involved.
Comments:
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)
Rationale and Criteria used for Inclusion:
- Future agency use cases.
Comments:
Little vendor support to date.
SAML token profile for Web Services Security (WSS)
SOAP Message Security v1.1
Rationale and Criteria used for Inclusion:
- Future agency use cases. WSS Addressing endorsed by W3C and vendors.
Comments:
Profiles relating to SAML over Web services are to be refined after browser based profiles are complete.
Authentication Query
Rationale and Criteria used for Inclusion:
- Future agency use cases.
Comments:
Uses SOAP binding.
Authorisation Decision Query
Rationale and Criteria used for Inclusion:
- When detailed use case proposed by agency.
Comments:
Referred to in the ESAA RFP, 30 August 2005. Uses SOAP binding.
