4. The benefits of identity federation
Many users of the Internet accumulate multiple digital identities, which they use to access a variety of online services. Typically the format of the username and password (or other credential) used to authenticate the user varies from website to website. For example Joe Bloggs may:
- Logon to his online banking account using his customer number 123456789
- Identify himself to his frequent flyer portal as jbloggs
- Use a travel portal as jb1234
- Access an online auction website as joe.bloggs@isp.net.nz.
All these digital identities represent one person. A single user will often use the same password to access most online services. These passwords are rarely, if ever, changed.
The benefits of identity federation, where agencies agree a common approach for all-of-government or sector-wide identity management, include:
- Simplicity. The end user has a single username and password (or other authentication key such as one-time passwords, software tokens or hardware tokens) to access services.
- Ease of introduction of new services. Building and deploying new online services is simple and fast as the security infrastructure for each new service does not have to be defined and built each time.
- Cost effectiveness and efficiency. The cost of building, maintaining and operating an authentication service is lower when there is no infrastructure duplication.
- Security. Enables a user and/or a Service Provider to use an existing Identity Provider, which assures an appropriate level of evidence and ongoing confirmation of identity. Users are also more likely to choose appropriately constructed passwords and change them regularly.
Where applicable and permissible, identity federation may incorporate 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. The benefits of SSO for the end user, in addition to the benefits of identity federation, include:
- Consistent view. Online services provided by multiple Service Providers appear to the user as being a single ‘joined up’ or shared service.
- Speed. Moving from one service provider to another is quick when there is no requirement to re-authenticate.
- Ease of use. Accessing a wide variety of online services is easy when the user is not required to re-authenticate when moving between Service Providers. The end user is only required to logon to the first service they access. Thereafter, they can ‘click-through’ to other services without needing to re-authenticate.
Please note that adopting the approach outlined in this framework and the NZ SAMS does not relieve agencies of the need to address the policy implications of any implementation of federated identity. Nor does it relieve agency obligations under the Privacy Act, nor the need for continuity planning and management of the risks associated with liability and trusted relationships. As identity information can encompass particularly sensitive personal information, it may be useful to conduct a privacy impact assessment (PIA) before implementing identity federation solutions.
Essential functionality for security assertion messaging
Security assertions about users need to be exchanged between different websites to enable identity federation. Security assertions are passed from an Identity Provider to a Service Provider via a message structured to an agreed standard, in an agreed order, using an agreed transport mechanism e.g. web browser or server-to-server Web Service.
Security assertion messaging addresses the following technical limitations:
- Non-interoperability of identity management applications. Identity management products may implement identity federation using a range of proprietary methods but use an agreed messaging structure.
- Confidentiality and integrity of Web Services in machine/application-based messages, specifically how to ensure end-to-end confidentiality and integrity. Web Services (server-to-server or application-to-application messaging) are increasingly used as part of identity federation solutions.
- Browser-based cookie limitations. Many existing identity federation systems use browser-based cookies to keep temporary information about a user’s interaction with a web site so that re-authentication is unnecessary. This is typically described as “maintaining state”. Because browser-based cookies are not transferable between DNS domains, they cannot be used to facilitate identity federation for services from multiple domains.
One of the most well-known examples of a security assertion messaging standard is the XML-based Security Assertion Markup Language (SAML). A SAML assertion contains one or more statements about a user. For example:
- An authentication statement – ‘The user jb1234 authenticated with a password at 9:03am’.
- An attribute statement – ‘The user jb1234 is a manager’.
- An authorisation statement – ‘The user jb1234 has a $500 spending limit’.
- Other user-defined statements that may be useful in the context of the online services being used.
Figure 1 summarises the sequence of events when a user logs into a Service Provider:
- The user connects to the Service Provider’s website.
- The Service Provider notices that the user is not logged in and redirects them to the Identity Provider to verify their identity.
- The user presents their online credentials to the Identity Provider.
- The user is provided with a security assertion to access the Service Provider’s website and they are redirected back to that site.

The essential components for identity federation are:
- A user wishing to access resources from a Service Provider.
- A Service Provider requiring confirmation of the user’s identity.
- An Identity Provider to provide confirmation of identity.
- A mechanism for users to access the websites of the above parties such as a web browser.
- An agreement between all three parties on what information, formats and protocols should be used to enable secure messaging between them.
- The establishment of a commonly agreed linkage between the Identity Provider and Service Provider to enable secure messaging between them.

