4.1 Audience
The intended audiences for this Standard are those people responsible for the development and security of agency information and IT systems, such as enterprise architects, security analysts, and developers.
4.2 NZ e-GIF status
Upon approval by the e-GIF Management Committee, this Standard will enter the NZ e-GIF as Under development (U) and graduate to Recommended (R) after a successful, documented implementation. This Standard is expected to graduate to Adopted (A) once there is a track record of proven successful implementation.
For guidance on agency responsibilities for compliance with the NZ e-GIF standards at each status level, refer to the latest version of the NZ e-GIF.
4.3 Accessing advice on this Standard
Advice on this Standard can be obtained from:
e-GIF Manager
Office of the GCIO
Email: e-gif@dia.govt.nz
Web: www.ict.govt.nz
The State Services Commission is the agency responsible for this Standard.
4.4 Interpretation
The following words defined in Key Words for Use in RFCs to Indicate Requirement Levels (RFC 2119) are used in OASIS SAML v2.0 and this Standard:
'MUST' and/or 'REQUIRED' – identify a mandatory requirement for compliance with this Standard.
'SHOULD' – refers to practices that are advised or recommended.
'MAY' – refers to practices that are optional.
Agencies deviating from a 'SHOULD' in their practices MUST document:
the reason for the deviation
an assessment of the residual risk resulting from the deviation
a date by which the decision will be reviewed
management's approval of the above.
When cross-referencing to other sections of this Standard, the number only may be quoted. The full titles of referenced documents cited in this Standard are given in the list of referenced documents before the appendices.
4.5 Conformance and compliance with this Standard
4.5.1 Principles
Conformance and compliance with this Standard rests on the following fundamental compliance principles:
That conformance and compliance is constrained by the scope of this Standard (see section 2).
That privacy and security of customer-related information in both transport and storage processes and procedures is paramount.
That predictable interoperable implementations with agencies external to the sector (such as but not limited to the GLS and the proposed IVS) is an overriding requirement. Interoperability internal to a sector (where authentication standards may already exist and/or where the impact of non-compliance can be mitigated) is a secondary consideration.
That the customer experience for individuals interacting with service agencies that arises from the design of the GLS, the proposed IVS, and service agency sites already transacting online with significant numbers of service users, should be reflected in successive implementations. This will assist in offering a predictable service user experience thereby improving confidence in and likely uptake of successive online services.
4.5.2 Conformance and compliance for products and applications
To provide guidance to implementers, the conformance and compliance requirements for products and applications, whether bespoke, open-source or commercial-off-the-shelf software (COTS), are summarised below.
Table 2 - Conformance and compliance requirements
All products and applications
Implementers MUST adopt the OASIS SAML v2.0 Standard as an overriding requirement, with specific mandatory compliance with the Conformance Requirements (in particular the Operational Modes) and Metadata Specifications. It is important that all solutions (i.e. vendor and agency-developed solutions) accepted by deploying agencies are also compliant with each of the profiles, bindings, protocols and assertions that support the New Zealand government agency usage patterns published in this Standard and in their own Request(s) For Proposals.
All products and applications interfacing with the All-of-government Authentication Programme's shared services
Implementers MUST self-certify all (i.e. vendor and agency-developed) service provider applications developed to interface to the all-of-government authentication shared services, against the igovt Messaging Test Sites proposed for SAML v2.0 conformance as appropriate.
Vendor products and applications with extended functionality
Where a vendor SAML implementation uses extended functionality (e.g. Identity Provider Proxy), implementers SHOULD obtain applicable extended conformance certification from Liberty Alliance.
It is the responsibility of service agencies to accept, as a minimum, solutions that have evidence-based conformance and compliance from the methods above.
Conformance to and compliance with NZ SAMS by NZ government agencies involves designing implementations using a combination of the applicable SAML v2.0 Specifications constrained by NZ SAMS. If the proposed use case cannot be delivered through a design complying with this Standard, the implementer is strongly advised to seek guidance from the authors of this Standard (the Secure Messaging Working Group) at the contact points in 4.3. Additional OASIS SAML v2.0 profiles and specifications will be constrained in subsequent releases of this Standard. Implementers are invited to propose additional agency use cases and published SAML v2.0 profiles for prioritised constraint in NZ SAMS.
A summary of compliance requirements is located in section 7 – Summary of Compliance Requirements from Part 1.
4.6 Definitions
Asserting party [SAML]
Informally, an instance of a SAML authority.
Assertion [SAML]
A piece of data produced by a SAML authority regarding either an act of authentication performed on a subject, attribute information about the subject, or authorisation data applying to the subject with respect to a specified resource.
Attribute [SAML]
A distinct characteristic of an object (in SAML, of a subject). An object's attributes are said to describe it. Attributes are often represented as pairs of attribute name and attribute values ... often referred to as attribute pairs [Edited]
Attribute assertion [SAML]
An assertion that conveys information about attributes of a subject.
Attribute authority [SAML]
A system entity that produces assertions.
Authentication [Guide]
Process of establishing, to the required level of confidence, the identity of one or more parties to a transaction. Consists of identity management (establishing who you are) and logon management (confirming who you are). In particular for NZ SAMS, authentication is used in the commonly understood sense of a customer logging onto a service with their username and authentication key. This is consistent with the logon management aspect of the general authentication definition above.
Authentication key [Guide]
Method used by an individual to authenticate his or her identity over the Internet. Examples of authentication keys include passwords, one-time passwords, software tokens, hardware tokens, and biometrics. Authentication keys are also referred to as keys. As used in this Standard, 'Authentication key' also includes a username. This is equivalent to the use of 'Logon' or 'Credential' by international standards bodies.
Authorisation [SAML]
The process of determining, by evaluating applicable access control information, whether a subject is allowed to have the specified types of access to a particular resource. Usually, authorisation is in the context of authentication. Once a subject is authenticated, it may be authorised to perform different types of access.
Back channel [SAML]
Direct communications between two system entities without 'redirecting' messages through another system entity such as an HTTP client (e.g. a user agent). See also front channel.
Binding, Protocol binding [SAML]
Generically, a specification of the mapping of some given protocol's messages, and perhaps message exchange patterns, onto another protocol, in a concrete fashion. For example, the mapping of the SAML <AuthnRequest> message onto HTTP is one example of a binding. The mapping of that same SAML message onto SOAP is another binding. In the SAML context, each binding is given a name in the pattern 'SAML xxx binding'.
Cookie [Webopedia]
A piece of information stored in a browser by a web server, which is then sent back to the web server each time the browser requests a page from that server.
Cryptographic keys [Guide]
Protected values (in terms of their confidentiality and integrity) that are used in cryptographic operations.
Entity, System entity [SAML] [SSC]
An active element of a computer/network system. For example, an automated process or set of processes, a subsystem, a person or group of persons that incorporates a distinct set of functionality (RFC2828). NOTE – NZ SAMS also refers to 'machine entity' to make an entity such as a computer distinct from an entity that encompasses a person or group of persons.
Evidence of identity (EOI) process [Guide]
Process by which an agency establishes confidence in an individual's identity.
Federated identity [SAML] [SSC]
A principal's identity is said to be federated between a set of providers when there is an agreement between the providers on a set of identifiers and/or attributes to use to refer to the principal. Identity Federation – the act of creating a federated identity on behalf of a principal. NOTE – NZ SAMS uses the terms: 'Federated identifier' to mean the identifier unique to an individual's identity paired with the particular service agency with which the individual transacts. 'Federated logon tag' to mean the name given to the federated identifier used in the GLS implementation.
Federation [SAML]
This term is used in two senses in SAML:
a) The act of establishing a relationship between two entities. b) An association comprising any number of service providers and identity providers.
Front channel [SAML]
The 'communications channel' that can be effected between two HTTP-speaking servers by employing 'HTTP redirect' messages and thus passing messages between each via a user agent, e.g. a web browser, or any other HTTP client (RFC2616). See also 'back channel'.
Government Logon Service (GLS) [Guide]
An all-of-government shared service that provides ongoing reconfirmation of online identity to participating agencies to the desired level of confidence.
Government Shared Network (GSN) [SSC]
The Government Shared Network (GSN) enables government agencies to collaborate securely and more cost effectively. The shared network improves the delivery of information and services to the New Zealand public. Phase 1 includes interagency linking, wide area network links, internet services and remote access services.
Hardware token [Guide]
Specialised hardware device that protects cryptographic keys and performs cryptographic operations. Use of the hardware token normally requires entry of activation data such as a password or biometric.
Identifier [SAML]
This term is used in two senses in SAML:
a) One that identifies. b) A data object (for example, a string) mapped to a system entity, which uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it.
An identifier is essentially a 'distinguished attribute' of an entity. See also 'attribute'.
Identity Provider (IdP) [SAML]
A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Provider: a generic way to refer to both identity providers and service providers. (An example of an identity provider is the Government Logon Service.) NOTE – In the nomenclature of actors enumerated in the Assertions and Protocols Specification [SAMLCore] the identity provider is synonymous with a 'SAML Authority.'
Identity-related risk [Guide]
Any risk for a particular service that results from an individual's identity being incorrectly attributed. Also refer to the Evidence of Identity Standard for further details.
Identity Verification Service (IVS) [Guide]
An all-of-government shared service that provides individuals with the option to verify their identity authoritatively, online, and in real-time with participating agencies to a passport level of confidence.
igovt
The brand for the All-of-government Authentication Programme all-of-government shared services, i.e. the Government Logon Service, Identity Verification Service, and Future Services.
Logon, Sign-on [edited] [SAML]
The process whereby a service user presents credentials to an authentication authority, establishes a simple session, and optionally establishes a rich session. (Logout, Logoff, Sign-off: The process whereby a service user signifies desire to terminate a simple session or rich session.)
Man-in-the-middle attack [Webopedia]
A man-in-the-middle attack (MITM) is an active internet attack where the person attacking attempts to intercept, read or alter information moving between two computers.
Mutual authentication [Guide]
Where both entities authenticate to each other (the authentication is normally based on the same or closely similar methods).
NIST [Webopedia]
National Institute of Science and Technology.
NZ e-GIF [Guide]
E-government interoperability framework – a collection of policies and standards endorsed for New Zealand government information technology (IT) systems.
OASIS [Guide]
Organisation for the Advancement of Structured Information Standards (OASIS) is a not-for-profit international consortium that drives the development, convergence and adoption of e-business standards.
Online service [Guide]
Service that an agency offers through an interactive online delivery channel.
Party [SAML]
Informally, one or more principals participating in some process or communication, such as receiving an assertion or accessing a resource.
Principal [SAML]
A system entity whose identity can be authenticated. (Principal identity: A representation of a principal’s identity, typically an identifier.)
Profile [SAML]
A set of rules for one of several purposes; each set is given a name in the pattern 'xxx profile of SAML' or 'xxx SAML profile'. Included are:
(a) Rules for how to embed assertions into and extract them from a protocol or other context of use. (b) Rules for using SAML protocol messages in a particular context of use. (c) Rules for mapping attributes expressed in SAML to another attribute representation system. Such a set of rules is known as an 'attribute profile'.
Proxy [SAML]
An entity authorised to act for another. This includes:
(a) Authority or power to act for another. (b) A document giving such authority.
Relying party [SAML]
A system entity that decides to take an action based on information from another system entity. For example, a SAML relying party depends on receiving assertions from an asserting party (a SAML authority) about a subject. (See also the definition of 'asserting party' above). NOTE – In the nomenclature of actors enumerated in the Assertions and Protocols document, section 3.4 [SAMLCore] the relying party is the request issuer and the service provider.
Requester, SAML requester [SAML]
A system entity that utilises the SAML protocol to request services from another system entity (a SAML authority, a responder). The term 'client' for this notion is not used because many system entities simultaneously or serially act as both clients and servers. In cases where the SOAP binding for SAML is being used, the SAML requester is architecturally distinct from the initial SOAP sender.
Resource [SAML]
Data contained in an information system (for example, in the form of files, information in memory, etc), as well as:
(a) A service provided by a system. (b) An item of system equipment (in other words, a system component such as hardware, firmware, software, or other documentation). (c) A facility that houses system operations and equipment (RFC2828).
SAML uses resource in the first two senses, and refers to resources by means of URI references.
Responder, SAML responder [SAML]
A system entity (a SAML authority) that utilises the SAML protocol to respond to a request for services from another system entity (a requester). The term 'server' for this notion is not used because many system entities simultaneously or serially act as both clients and servers. In cases where the SOAP binding for SAML is being used, the SAML responder is architecturally distinct from the ultimate SOAP receiver.
Security [SAML]
A collection of safeguards that ensure the confidentiality of information, protect the systems or networks used to process it, and control access to them. Security typically encompasses the concepts of secrecy, confidentiality, integrity, and availability. It is intended to ensure that a system resists potentially correlated attacks.
Security Assertion Markup Language (SAML) [Guide]
An XML-based standard that defines messages for communicating a range of security-related statements about individual parties, including their authentication.
SAML artifact [SAML]
A small, fixed-size, structured data object pointing to a typically larger, variably-sized SAML protocol message. SAML artifacts are designed to be embedded in URLs and conveyed in HTTP messages, such as HTTP response messages with '3xx Redirection' status codes, and subsequent HTTP GET messages. In this way, a service provider may indirectly, via a user agent, convey a SAML artifact to another provider, who may subsequently dereference the SAML artifact via a direct interaction with the supplying provider, and obtain the SAML protocol message. Various characteristics of the HTTP protocol and user agent implementations provided the impetus for concocting this approach. The HTTP Artifact binding section of [SAMLBind] defines both the SAML artifact format and the SAML HTTP protocol binding incorporating it.
SAML authority [SAML]
An abstract system entity in the SAML domain model that issues assertions. See also 'attribute authority', (and 'authentication authority' and 'policy decision point' (PDP) in the OASIS SAML v2.0 Glossary) [edited]. NOTE – In the nomenclature of actors enumerated in the Assertions and Protocols document [SAMLCore] the SAML authority is usually synonymous with 'identity provider'.
Security context [SAML]
With respect to an individual SAML protocol message, the message's security context is the semantic union of the message's security header blocks (if any) along with other security mechanisms that may be employed in the message's delivery to a recipient. With respect to the latter, examples are security mechanisms employed at lower network stack layers such as HTTP, TLS/SSL, IPSEC, etc. With respect to a system entity, 'Alice', interacting with another system entity, 'Bob', a security context is nominally the semantic union of all employed security mechanisms across all network connections between Alice and Bob. Alice and Bob may each individually be, for example, a provider or a user agent. This notion of security context is similar to the notion of 'security contexts' as employed in RFC2743, and in the Distributed Computing Environment (DCE), for example.
Service [Guide]
An activity conducted between a customer and a government agency, in accordance with the functions for which that agency is accountable.
Service provider (SP) [SAML]
A role donned [taken] by a system entity where the system entity provides services to principals or other system entities. In the context of this Standard, it is a government agency providing online services. NOTE – In the nomenclature of actors enumerated in the Assertions and Protocols document, section 3.4 [SAMLCore], the service provider is the request issuer and the relying party.
Service risk category (SRC) [SSC]
Each service risk category is defined based on the identity-related risk of a service and is detailed in the Evidence of Identity Standard [EOIS].
Service user [Guide]
Person interacting with agencies to access services over the Internet.
Session [SAML]
A lasting interaction between system entities, often involving a principal, typified by the maintenance of some state of the interaction for the duration of the interaction.
Single sign-on (SSO) [Webopedia]
An authentication process in a client/server relationship where the user, or client, can enter one name and password and have access to more than one application or access to a number of resources within an enterprise. Single sign-on takes away the need for the user to enter further authentications when switching from one application to another. Single sign-on is also spelled single sign on and abbreviated as SSO.
Single sign-off [Wikipedia]
Single sign-off is the reverse of single sign-on, where a single action of signing out terminates access to multiple software systems.
SOAP [Webopedia]
Short for Simple Object Access Protocol, a lightweight XML-based messaging protocol used to encode the information in Web Service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of internet protocols, including SMTP, MIME, and HTTP.
Subject [SAML]
A principal in the context of a security domain. SAML assertions make declarations about subjects.
Transport Layer Security(TLS) [Guide]
Like the Secure Sockets Layer (SSL) protocol, which it supersedes, TLS provides a cryptographically protected channel for web browser exchanges. TLS is defined by the Internet Engineering Task Force. TLS is similar to the older Secure Socket Layer (SSL) protocol and is effectively SSL v3.1.
Uniform Resource Identifier (URI) [Webopedia]
Uniform Resource Identifier is the generic term for all types of names and addresses that refer to objects on the World Wide Web. (Uniform Resource Locator (URL) is one type of URI.)
Web Services [Webopedia]
A term used to describe a standardised way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over IP.
W3C [Webopedia]
Short for World Wide Web Consortium, an international consortium of companies involved with the Internet and the Web. The W3C was founded in 1994 by Tim Berners-Lee, the original architect of the World Wide Web. The organisation's purpose is to develop open standards so that the Web evolves in a single direction rather than being splintered among competing factions.
XML Attribute [SAML]
An XML data structure that is embedded in the start-tag of an XML element and that has a name and a value. For example, the italicised portion below is an instance of an XML attribute:
<Address AddressID=”A12345”>...</Address>
XML Element [SAML]
An XML data structure that is hierarchically arranged among other such structures in an XML document and is indicated by either a start-tag and end-tag or an empty tag. For example:
<AssertionConsumerService>...</AssertionConsumerService>
Special notes to the definitions
Readers should note that the use of the term 'Authentication key(s)' in this Standard is equivalent to the use of 'Logon' or 'Credential' by international standards bodies. That is, this Standard uses 'Authentication Key' to mean both the username and the method of authentication over the Internet. This use of the term differs from the definition used in the NZ e-GIF authentication standards. 'Authentication key(s)' is not to be confused with 'Cryptographic keys' (symmetric or asymmetric key pairs).
Sources for definitions:
Glossary for the OASIS Security Assertion Markup Language (SAML) v2.0 [SAML]
SAML Assertions and Protocols Document [SAMLCore]
Guide to Authentication Standards for Online Services [Guide]
From http://www.webopedia.com [Webopedia]
From http://www.wikipedia.com [Wikipedia]
State Services Commission [SSC]
The One.govt Network [https://ict.govt.nz/common-capabilities/communications/onegovt].