5. Guiding Principles for NZ SAMS

[ Table of Contents ]

5.1 Introduction to identity federation

In its first release, this Standard prescribes the assertion message formats used in the confirmation of user authentication. The authentication assertions or artifacts are to be securely transported in a message format from authenticating agencies to service agencies, to achieve a single agreed approach to all-of-government online authentication. In effect, the entities in the roles of service providers (SPs) and the authentication (or identity) provider(s) (IdPs) are trusted in a federated configuration.

This will be effected by a service user using a web browser, attempting to access a resource directly at an SP website. When the person attempts to use an authenticated service, their web browser will be redirected to the IdP which, after authenticating them, will redirect their web browser back to the SP's website. Capability exists in this Standard for a person to use their browser to authenticate themselves by logging on to any participating SP website without having to authenticate again – typically referred to as single sign-on (SSO). Single sign-on is where agencies agree that an authenticated user from one agency's online service may access another agency's online service without re-authentication. Where applicable and permissible, identity federation may incorporate single sign-on.

5.2 NZ government use cases and usage patterns

The Secure Messaging Working Group drafting this Standard sought and reviewed agency use cases. This included agency-to-IdP, agency-to-multiple IdP and intra-sector agency-to-agency authentication and related secure message exchange. The Working Group derived a generic usage pattern out of the use case message sequence designs forwarded by the Inland Revenue Department, the Ministry of Education, the Ministry of Agriculture and Forestry, and the State Services Commission's GLS. See Appendix A for details.

The use cases (not surprisingly) exhibited very similar features. The usage patterns were mapped to applicable OASIS SAML v2.0 profiles in order to create a 'level playing field' and to lower the cost of ownership for subsequent proposed alternative solutions. The 'generic' NZ government usage pattern is shown in Figure 2.

Figure 2 - Generic NZ government usage pattern

The summarised communication flow for the generic usage pattern is:

1. The service user attempts to access a resource at an SP agency website.
2. The SP agency may place a session cookie or similar object on the service user's browser to establish the local authentication session (see Appendix C for further guidance on the use of cookies.
3. The SP agency's service user is redirected via their web browser to a logon page.
4. The IdP agency presents the web user with a logon page.
5. SP agency's service user submits logon information on the logon page.
6. The IdP agency will respond to the SP agency with a message via the service user's browser. The message contains either an assertion or an artifact, depending on the SAML binding used. Where the message contains an assertion (i.e. POST binding), the SP agency uses the assertion to authenticate the service user using its own internal processes and the pattern is complete. Where the message contains an artifact (i.e. Artifact binding), the SP agency dereferences the artifact to determine the IdP and continues with Step 7.
7. Where the message contains an artifact, the SP includes the artifact in a request (such as an application-to-application digitally-signed SOAP message based Web Services call) to the IdP via a 'back channel' (such as an appropriately secured SSL/TLS leased data connection or Virtual Private Network) to receive the assertion.
8. The IdP resolves the request by sending a message with the assertion reserved for the artifact via the mechanism described in (7) above.

Given the conformance and compliance principles outlined in section 4, future designs of online authentication SHOULD reflect this generic usage pattern.

5.3 Significant issues in federated identity management

Privacy and security are the overarching concerns. In a federated identity environment, the authentication process involves an interaction between a service user and entities acting in the roles of an SP and an IdP. Security must be maintained at and between all three locations. It requires significant effort and resources to secure the SPs and IdPs.

In general, service users' PCs, and in particular web browsers, cannot be reliably secured. Persistent cookies (where a small file placed on the service user's PC by a website visited by the service user) cannot readily be used to securely exchange data across domains. On the other hand, transient cookies (where an object is placed in memory temporarily for period of the session) are used as part of most solutions for maintaining 'local state', for example an SP maintaining a service user's authentication session. Use of cookies with their lack of content standards, cross-domain limitations and well-publicised security concerns has been severely restricted by the New Zealand Government Web Standards and Recommendations v1.0 [NZGWSR]. In the context of security assertion messaging and in particular the development of this Standard, the Secure Messaging Working Group has interpreted the guidance to mean that cookies do not contain session state, but merely contain a reference to session state that is stored and maintained on the agency site. (See Appendix C for further guidance on the use of cookies in the context of NZ SAMS.)

Instead, reliance has been placed on Internet transport standards such as HTTP. This allows URLs to be used when interacting with a service user at a browser. The W3C XML and SOAP standards are used to define message layouts. Sensitive messages, assertions and artifacts can be made secure with encryption and digital signature techniques. Digital signatures and digital certificates are not typically specified for service users or PCs because they are complex to administer; too complex for general home users. However, digital signatures and certificates play a significant security role for machine-machine system interactions between SP agencies and IdP agencies.

5.4 The OASIS SAML v2.0 solution

To meet these privacy and security requirements, the OASIS SAML v2.0 Specifications use a number of data formatting, messaging, digital signature, encryption, and Internet transport standards to specify the layout and transport of security messages, assertions and artifacts and to provide secure and effective authentication in a federated environment.

The OASIS SAML v2.0 Specifications provide profiles – examples of particular message flows that, together with the appropriate protocol binding to the transport layer, achieve authentication. Asynchronous bindings address the SP or IdP-to-service user interactions (or vice versa), via web browsers and web servers. Synchronous bindings address direct SP-to-IdP interactions (or vice versa) between their respective applications with SOAP and Web services. While SOAP and Web services are not the only ways to address application-to-application messaging, in the first release of the OASIS SAML v2.0 Standard it is the SOAP/Web services transport option that is profiled, and this is supported by the emergence of a New Zealand government online service usage pattern applicable to the SOAP/Web service.

OASIS SAML v2.0 directly supports XML encryption of name identifiers, assertions, and identity attributes within messages. OASIS SAML v2.0 also supports the use of encryption and digital signatures on sending and receiving servers for the web browser transport.

5.5 Entities, parties and authorities in OASIS SAML v2.0

The concepts of entities, parties and authorities are used in SAML v2.0 messaging processes and further explanation here will assist readers.

In SAML v2.0, an entity is either an 'asserting party' (creates assertions) or a 'relying party' (consumes assertions). The information to create assertions is provided by services called 'authorities'.

In the first release of NZ SAMS, the Authentication Authority and Attribute Authority services are used. Later releases of NZ SAMS may also use an Authorisation Authority service, often referred to as a Policy Decision Point. In this context, Attribute Authority isn't a 'role'; it is simply a service that supplies identity attribute information.

An IdP is an asserting party 'role' and an SP is a relying party role for a SAML entity. To do its work, an IdP needs to interface with, at a minimum, an Authentication Authority service, but it often also interfaces with an Attribute Authority service. The IdP creates web SSO assertions with <AuthenticationStatement> elements (mandated by SAML in the usage of the <Response> message) and optional <AttributeStatement> elements (not specified in this release of NZ SAMS) using information it obtains from these authorities.

A SAML entity (either an IdP or an SP) can additionally take on the role of an attribute authority – also an asserting party role for a SAML entity. This attribute authority role interfaces with an attribute authority to obtain identity attributes just as an IdP does. The assertions that the attribute authority creates only contain <AttributeStatement> elements.

Later in the messaging process when an SP consumes a web SSO assertion that contains attribute statements, it processes them by passing them to what SAML v2.0 calls 'attribute consuming services'. An SP can have optional attribute consuming services defined as part of its 'role.' But a client that makes queries to an attribute authority role at a SAML entity is not an SP. It is taking on a 'query requester' role. This role is a relying party role just as an SP is a relying party role.

5.6 Overarching business and design rules for NZ SAMS

While the OASIS SAML v2.0 Standard is relatively prescriptive, it offers a number of implementation options to cater for a variety of implementation designs in play around the world. Therefore the use of SAML v2.0 alone does not guarantee predictable user and implementation experiences. Nor does the use of SAML v2.0 alone guarantee interoperability.

To this end, the Secure Messaging Working Group has agreed a set of fundamental implementation business and design rules in order to more tightly prescribe the SAML v2.0 Standard for New Zealand government implementations.

In a New Zealand government implementation of a federated online environment (where authentication of the service user is separated from the service provider agencies) the following business and design rules apply:

• No reliance on the security of the service user's personal computer – Due to the difficulty in securing every personal computer (PC) on the Internet, no reliance can be placed upon the service user's PC for the transport of authentication-related messages and for installing client-side authentication software (with the exception of multi-factor authentication software applications which are out of scope of this Standard).
• Federated identifier – Service users who logon at the authentication provider website must be given something (a unique federated identifier) that they can present to service provider agency websites as confirmation that they have been successfully authenticated.
• No universal identifier – The federated identifier must meet Information Privacy Principle 12 (IPP12) of the Privacy Act 1993. That is, it cannot be assigned as a universal identifier.
• State persistence – If the service user goes to the agency SP website and encounters a step(s) in a service that requires the service user to be authenticated, the service user must be redirected to the authentication provider agency website. The redirection process and application logic must be implemented in such a way that the authentication provider agency website will redirect the service user back to the service provider agency website once they have authenticated, bearing their authentication credential, 'handle' and session ID. The service provider agency website must then be able to seamlessly resume the interrupted service step.
• Verified federated identifier – The effort to compromise the security of the authentication credential must be prohibitive. The service provider agency website must be able to verify that the credential was issued by some party that the service provider agency website trusts. Typically this is achieved using digital certificates for the servers involved in the exchange.
• Verified messages – The effort to compromise the security of any messages, or fragments of messages, that support the above requirements must be prohibitive. The service provider agency website and authentication provider agency website must be able to verify that the messages were issued by a party within the federation of websites. Typically this is achieved by signing and/or encrypting the message parts.
• Universal services – Any service provider agency with an online presence and seeking to authenticate their service users on the Internet must be able to participate in the federation.
• Audit Trail – Security assertion sessions must have an accompanying audit trail. Refer to [NZSIT402] Part 2, Chapter 7 for guidance, specifically 'Audit Logs and Analysis', 'Audit Trail Events' and 'Management of Audit Logs'.
• Archive management – Establish practices for managing archives containing signed or encrypted data. Examples of potential issues are:
  • Logs that contain information that was signed with certificates that have since expired may be difficult to validate. Without trusted timestamps it would be unclear whether the signed object was created before the certificate was revoked or expired.
  • Encrypted elements in the logs will likely require the private key of the recipient to decrypt. If those keys have not been archived it may be impossible to read the old logs.

Refer to [NZSIT402], Part 2, Chapter 3, para 2.3.23 'Data migration and Archiving', 'Maintaining access and access controls', and [S17799], 12.3.2 (where there is also a further reference to AS/NZS ISO/IEC 11770).