Guidance and Resources

6.1 Authentication: Profiles and Bindings introduction

This section details the profiles and bindings selected for authenticationdeployments of OASIS SAML v2.0 Specifications by New Zealand government agencies. The selection was based on a set of criteria agreed by the working group and is set out in Appendix B. Limiting the number of profiles and bindings will enable:

• efficiency through reuse of message code
• predictability of the service user's online experience
• predictability in the design of services exchanging assertions between IdPs , SPs and the all-of-government authentication services
• interoperability by ensuring that applications support the agreed binding sets from the outset.

Other profiles and bindings (typically a pair/set) from SAML v2.0 may be proposed to the Secure Messaging working group (see Section 4 for contact details). These sets MUST be based on well-documented usage patterns. They will be considered and refined by the working group for inclusion into the next revision of this Standard.

6.2 Authentication: NZ government generic usage patterns mapped to SAML v2.0 Profiles

These high level visual representations of the generic usage patterns for authentication shown below were derived by the working group from the message sequence designs forwarded by Inland Revenue, the Ministry of Education, the Ministry of Agriculture and Forestry and the State Services Commission's GLS. See Appendix A for details. Aside from minor differences, the authentication message sequence sets displayed very similar communication flows, with the service user, via his/her web browser, initiating the authentication process by attempting to access a resource at an SP agency website. The usage patterns are captured in Figure 3 in a generic diagram used to map to the applicable OASIS SAML v2.0 profiles and bindings selected for this Standard. SAML v2.0 refers to this usage pattern as a Service Provider (SP) initiated web browser Single Sign On (SSO) Profile.

6.2.1 SP initiated web browser SSO Profile

Figure 3 - SP initiated web SSO profile

The profile depicted in Figure 3 describes where a service user accesses a resource at a Service Provider (SP). The service user authenticates to the identity provider (IdP), which then produces an authentication assertion with input from the SP and the SP consumes the assertion to establish a security context for the service user. The use pattern reflecting this profile emerged from agencies that expect to use the GLS to authenticate their service users. The summarised communication flow for the generic usage pattern above 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 on the service user's browser.
3. The service user is redirected via his/her web browser to a logon page.
4. The authentication IdP agency presents the service user with a logon page.
5. The SP agency's service user submits logon information on the logon page.
6. The IdP agency website 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 v2.0 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 agency includes the artifact in a request (such as an application-to-application digitally-signed SOAP message over Web Services call) to the IdP agency to receive the assertion via a "back channel" (such as an encrypted and appropriately secured SSL/TLS leased data connection or Virtual Private Network in accordance with NZSIT 400 cryptosystem requirements).
8. The IdP agency resolves the request by sending a message with the assertion reserved for the artifact via the mechanism described in (6) above.

Further variations of this generic pattern are set out in 6.2.2 and 6.2.3, referred to by their OASIS SAML v2.0 Profile description. Each variation is briefly described based on the usage pattern supplied and the degree of complexity of the variation. For each of these Profiles, the Profile and its underlying usage pattern are briefly described.

6.2.2 IdP proxy (IdP extended)

Figure 4 - IdP Proxy (IdP Extended)

The profile depicted in Figure 4 is a variation on the generic SAML v2.0 Web browser SSO profile. It describes how an IdP contacted by an SP acts in the role of an SP (i.e. proxies) to a different (endpoint) IdP where the service user ultimately authenticates. The endpoint IdP returns an assertion that is used by the proxying IdP to build a new assertion for the originating SP to use. The use pattern reflecting this profile emerged from a number of agencies that expect to use the GLS (the endpoint IdP) for the act of authenticating, while managing all other aspects of the service user's session - SSO, authorisation and provisioning, identity attributes etc. NOTE - IdP Proxy is not explicitly detailed in the OASIS SAML v2.0 Profiles Specification. However it is featured in the OASIS SAML v2.0 Conformance Requirements (Table 3 'Extended IdP, SP' p 10, lines 187-188).

6.2.3 SP initiated with Name Identifier mapping profile

Figure 5 shows a combination of two profiles : the generic OASIS SAML v2.0 Web browser SSO profile combined with the Name Identifier mapping profile. It describes how a SAML entity assumes the role of an Attribute Authority for another SP, based on a previously successful authentication with a service user. This profile reflects the usage pattern whereby a service user registers for a service at a 'new' SP by allowing the identity attributes that have been stored at another SAML entity to be used to complete the registration process in a single logon session. Registering a 'new' service user at SP 2. SP 2 uses the authentication services of IdP 1 together with the Attribute Authority services of SP 1 in an Attribute Authority role. SP 2 must verify the identity of the 'new' service user. Assumption: In some previous event, the service user accessed SP 1, for example to update or maintain identity related information, and authenticated at IdP 1 for this purpose. A unique federated identifier (the IdP 1/SP 1 federated identifier) for this service user has already been exchanged at IdP 1 and SP 1.

Figure 5 - SP initiated with NameID mapping profile

The summarised communication flow for the generic usage pattern above is:

1. Service user accesses 'Register Service user' application at SP 2, where the service user explicitly gives permission for SP 2 to verify his/her identity.
2. The agency may place a session cookie or similar on the user's browser.
3. Redirected to IdP with an <AuthnRequest> message to log in.
4. IdP 1 presents service user with logon page.
5. Service user presents Authentication key(s).
6. Service user is redirected back to SP 2 with the IdP 1/SP 2 federated identifier in a POST binding (or with an artifact to be resolved by the SP via a 'back channel' SOAP binding, not detailed in figure 5. See 6.2.1).
7. Armed with the IdP 1/SP 2 federated identifier for this service user, SP 2 requests (i.e. a <NameIDMappingRequest> message) from IdP 1 an encrypted federated identifier (the IdP 1/SP 1 federated identifier) that SP 2 can use at SP 1 to obtain attributes for the service user. IdP 1 encrypts this identifier with the public key of SP 1 so that only SP 1 can decrypt it and thus interpret it as the IdP 1/SP 1 federated identifier for this service user.
   
   NOTE - This identifier is encrypted with a different symmetric key each time any SP ( other than SP 1 ) makes a < NameIDMapping Request > message to IdP 1 so it appears different to the SP in each event, but it is the same identifier (after decrypting) in each event from the perspective of SP 1.
8. IdP 1 issues a <NameIDMappingResponse> message via a 'back channel' SOAP binding. The <NameIDMappingResponse> carries the encrypted federated identifier usable at SP 1. This encrypted identifier is the IdP 1/SP 1 federated identifier.
9. SP 2 then issues an <AttributeQuery> message using the assertion query and request protocol to SP 1 containing the encrypted identifier received in (8) above.
10. SP 1 issues a <Response> message to SP 2 with the identity attribute assertion for the service user.

NOTE - Authentication information is not shared. When SP 1 provides attributes to SP 2 it is acting in the role of an Attribute Authority and simply responding to the fact of its possession of an encrypted federated identifier. It is not authenticating the service user, nor acting in the role of an IdP.

6.2.4 Authentication: OASIS SAML v2.0 profile selection

The applicable SAML v2.0 profile for the SP-initiated usage patterns identified in 6.2 is the Web Browser Single Sign On (SSO) Profile. In conjunction with the Web Browser SSO Profile, the following may apply:

• Artifact Resolution Profile MUST also be used where messages are exchanged directly (point-to-point usually via a secured leased line/VPN back-channel) between entities (e.g. an SP and an IdP), rather then via an intermediary (service user's browser)
• IdP Proxy variation essentially repeats (or doubles) the generic SSO usage pattern
• Name Identifier Mapping Profile may be required to provide a secure way of exchanging authentication information where the service user opts to register for a service at an SP that requires identity verification from two sources in one session (i.e. without the service user having to logon to each SP in succession).

To deploy the SAML v2.0 Web Browser SSO profile, the SAML v2.0 Authentication Request protocol is used in conjunction with the HTTP Redirect, HTTP POST and HTTP Artifact bindings. SSO bindings are summarised in 6.3.1 to 6.3.5. Outline deployment compliance requirements are offered in 6.4 and their NZ SAMS constraints detailed in Section 11.

To deploy the SAML v2.0 Name Identifier Mapping profile, the SAML v2.0 Assertion Query and Request protocol is used, bound to a SOAP-over-HTTP binding over a secured communication channel, such as the GSN.

6.3 Authentication: OASIS SAML v2.0 SSO Bindings

6.3.1 OASIS SAML v2.0 SSO bindings - introduction

SAML v2.0 bindings map SAML v2.0 protocol message exchanges onto standard messaging (transport) protocols. There are two Internet-based transport mechanisms reflected in current government agency usage patterns:

• Browser-based - where the transport is via a web browser (e.g. HTTP Redirect, HTTP POST , HTTP Artifact )
• Machine-based (Web Services) - where the transport is via (typically) server-to-server mechanisms (e.g. SOAP over HTTP) over a secured communication channel, such as the GSN.

NOTE – Definition of SOAP/HTTP/Web services is out of scope for NZ SAMS. The following SOAP based references are offered for completeness: NameIdMapping and AttributeQuery

.

6.3.2 OASIS SAML v2.0 SSO bindings – recommendations

There are only two recommended sets for binding the SAML v2.0 authentication message exchanges to transport protocols. Additional SAML profiles are supported using the SOAP binding. The recommended bindings are:

• SSO Binding set 1 - HTTP Redirect for the <Authn Request> message from the SP agency to the IdP and HTTP POST for the <Response> message for the response .
• SSO Binding set 2 - HTTP Redirect for the <AuthnRequest> message from the SP agency to the IdP and HTTP Artifact for carriage of the SAML artifact back to the SP combined with the SOAP over HTTP binding via an appropriately secured leased line/VPN back channel. The SOAP Binding is needed for the artifact resolution protocol messages, <ArtifactResolve> and <ArtifactResponse>.
• The SOAP binding requirements as specified in SOAP 1.1 from W3C for <NameIDMapping> and <AttributeQuery>.

6.3.3 OASIS SAML v2.0 SSO binding sets - selection criteria

Selecting a binding set most appropriate to the circumstances requires consideration of a number of factors including, but not limited to:

• The relative cost differential between HTTP (front channel) and SOAP/Web Services (back channel) solutions. For example, HTTP POST is considered easier to implement and requires fewer resources
• The agency's existing and proposed interoperating partners, and their existing interfaces. For example if the SP agency already uses the GLS as an IdP for authentication, it will have already invested in the 'back-channel' as part of the GLS interface requirement
• The Service Risk Category and security requirements of the transaction. Back channel solutions (properly implemented) are perceived to be more secure (albeit more expensive to implement) on the premise that if a service user never receives an assertion in his/her browser this element of risk of compromise is eliminated. However, front channel solutions can be successfully secured using digital signatures and encryption.

NOTE - Vendor support is not foreseen as an issue, since products that conform to the Feature Matrix in the SAML v2.0 Conformance Requirements Specification (whether or not they have been through the interoperability certification) are required to support both the POST and the Artifact bindings for (an IdP) sending or (an SP) receiving a Response message with an SSO assertion.

Other considerations include:

• the time frame required to get an authentication service online
• the SP's existing and planned IT architecture footprint
• the size of message placed in a URL (given that there is no consistency across web browser products on the management of this), which may limit the use of this binding to a subset of the SAML protocol messages. DEFLATE compression can mitigate this issue to an extent but does have restrictions. This is of particular concern for older web browsers.
• the relative processing overheads of digital signatures and encryption.

6.3.4 Encryption and digital signature considerations

Special attention is drawn to the delineation between privacy and integrity protection of messages at the transport layer (SSL 3.0 and TLS 1.0) from their privacy and integrity protection at the SAML protocol messaging layer. Transport layer security provides security during the communications between devices over the Internet by performing:

• authentication through a one-time verification of digital signatures on previously communicated data
• encryption through the agreement of a symmetric key that is used to encrypt the communication. By performing these operations, typically in Public Key Infrastructure (PKI) processes, transport security offers confidentiality during communication.

NOTE - The transport layer also provides some degree of integrity based on the confidentiality provided by the symmetric key encryption. Privacy/confidentiality and integrity protections afforded by SSL/TLS communication channels are only effective while the messages are in transit. No protections are provided by appropriately secured SSL/TLS once a message reaches the destination application (e.g. the service user's browser, an application servlet, etc).

Transport layer security should be used whenever sensitive communications between devices involve insecure networks. Once a communication is received, it is decrypted and the receiving application obtains the message in clear text.

In comparison, message security allows digital signing and encryption of certain message parts. Therefore, even if the confidentiality of the communication is compromised, the encrypted sections of the message may remain confidential, and the integrity of the digitally-signed sections can be verified.

Whenever:

• confidentiality is highly important, even after the communication of message is received, applicable message parts should be encrypted
• integrity is highly important, the message should be digitally-signed
• auditability is important, for example to enable non-repudiation, the message should be digitally-signed. Note that transport level solutions (e.g. HTTPS) have an important shortcoming from an audit trail perspective. This limitation occurs as unless the entire TLS stream is logged (which is generally unfeasible, or at least cumbersome) there will not be digitally-signed evidence to rely on after the communication.
• the service user is an intermediary during communication of a sensitive message, the message should be digitally-signed. An example MITM attack could occur when using the HTTP POST binding and the browser is compromised.

The OASIS SAML v2.0 Specifications support the use of XML Encryption for element privacy/confidentiality protection and XML Signature for element integrity protection and authentication of a message issuer.

At the message transport layer, appropriately secured SSL/TLS MUST be used for all browser to server exchanges. The use of appropriately secured SSL/TLS for server-to-server message exchanges (i.e. the SOAP channel) is required except when the communication takes place over a secured channel i.e. the GSN.

At the OASIS SAML v2.0 protocol message layer, complete SAML messages are never encrypted. Specific elements within the messages MAY be XML-encrypted to provide privacy protection of those elements. The elements that MAY be encrypted and specified in this release of NZ SAMS are:

• Unencrypted Element: <Assertion> (carried in protocol response messages)
  Encrypted Element: <EncryptedAssertion>
• Unencrypted Element: <NameID> (used in various messages and assertions)
  Encrypted Element: <EncryptedID>
• Unencrypted Element: <Attribute> (contained within the SAML assertion framework)
  Encrypted Element: <EncryptedAttribute>

For example, in an <AuthnRequest> protocol message, the optional <NameID> element in the <NameIDPolicy> element may be XML-encrypted to hide the <NameID> from systems for which the message is not intended.

OASIS SAML v2.0 supports the use of XML Signature to ensure the integrity of any of its protocol messages, and the specifications make it mandatory in many cases. In addition, if a SAML assertion is present within a protocol message, the assertion itself may also be signed. SAML v2.0 does not support signing of individual elements that may be carried within an assertion or protocol message (other than the assertion element).

XML Encryption and XML Signature can be combined within a protocol message exchange. For example, a SAML <EncryptedAttribute> element can appear within a SAML <EncryptedAssertion> and transmitted between parties in a signed SAML <Assertion> element of a <Response> message. It should be noted that attribute values can contain their own encryption. However, this encryption should not be unravelled by the SAML SSO layer code, but rather by the application layer (see discussion in Appendix D).

Consideration should be given to the deployment model used for IdPs, SPs and a SP's applications that depend on the secure exchange of SAML messages. If the deployment distribution of the components does not expose the deployment model to:

• unacceptable risk of tampering
• eavesdropping (i.e. if the applications are tightly coupled to the message endpoints)
• potential performance implications of encryption/decryption

and if:

• an audit trail of IdP assertions is not required

then transport layer security may be adequate to secure the environment and further signing and encryption of message parts may be superfluous.

More detail and compliance requirements for the transport layer can be obtained in the [NZSIT 402] document series. More detail and compliance requirements on the OASIS SAML v2.0 SSO binding sets is given in 6.4.

6.4 Deploying selected SAML v2.0 SSO bindings - Compliance Overview

6.4.1 SSO binding set 1 - HTTP Redirect and HTTP POST

This section describes the first of the two binding sets to be used by New Zealand government agencies.

Figure 6 - SSO binding set 1 - HTTP Redirect and HTTP Post

Table 3 - Message flows for SSO binding set one

Conformance and compliance considerations for Binding set 1 are noted below.

1. SSO Binding Set 1 is solely web browser based.
2. SSO Binding Set 1's transport channel MUST be secured using SSL v3 or TLS v1 from message 3 onwards to provide privacy and confidentiality protection of messages while in-transit.
3. SSO Binding set 1 uses the HTTP Redirect binding to carry the <AuthnRequest> message. The practical length limit of the URL means that the content of the message should be kept small, in order to restrict binding options for the message.
4. SSO Binding Set 1 uses the HTTP POST binding. Assertions MUST be signed in the HTTP POST binding in order to authenticate the IdP to the SP. The rationale for deciding whether or not to encrypt assertions is based on SAML rules, the sensitivity of the information being conveyed and the Service Risk Category (SRC) of the transaction.
5. SSO binding set 1 MAY be used by all Service Risk Categories (SRC) and MAY be used without encrypting assertions or assertion elements if agreed by the exchanging parties in accordance with the guidance in point 4 above.
6. If SSO binding set 1 is used, <OneTimeUse> MUST be enforced for the SP. A 'Compliance Test' ⁱ for <OneTimeUse> MUST be completed when using SSO binding set 1.

6.4.2 SAML v2.0 SSO binding set 2 - HTTP Redirect and HTTP Artifact with the Artifact Resolution profile

This section describes the second of the two binding sets to be used by New Zealand government agencies.

Figure 7 - SAML v2.0 SSO binding set 2 - HTTP Redirect and HTTP Artifact with the Artifact Resolution profile

Table 4 - Message flows for SSO binding set two

Conformance and compliance considerations for Binding set 2 are noted below.

1. SSO Binding Set 2 is web-and machine-based.
2. SSO Binding Set 2 has more steps than the solely web-based SSO Binding Set 1.
3. SSO binding set 2 MAY be used by all Service Risk Categories (SRC).
4. Messages 7 and 8 use the SAML v2.0 Artifact Resolution profile.

6.4.3 Message acceptance and graceful failure - guiding principles

The specific content of security messages conveying authentication assertions and related secure messaging content may vary between usage patterns and applications. The guiding principles for message acceptance and failure to be agreed by the exchanging parties and programmed into agency application logic include:

1. The message MUST parse as well-formed and valid against the SAML v2.0 schema.
2. All request messages received by a recipient SHOULD return a response, even if the recipient will not process the message for any reason. Refer to the applicable 'Error Reporting' subsections in the SAML Specifications.
3. Messages that require encryption MUST be encrypted using the sender's public key before sending, and be decrypted by the receiver with the receiver's private key.
4. Messages that contain a <Conditions> element with attributes such as NotBefore or NotOnOrAfter time expiry MUST NOT be processed if current time does not meet the conditions. General processing rules and the notion of validity as it relates to <Conditions> are found in the SAML Core (Assertions and Protocols) Specification.
5. Messages that are conveyed using the POST profile, MUST be protected using <Condition>/<OneTimeUse>. This prevents replay of the message by MITM attacks. However, confidentiality against MITM can only be achieved by using <EncryptedAssertion>.

Footnote

[ⁱ Details of what is involved in the ‘Compliance Test’ are to be determined.]