1. From Identity and Authentication ‘point solutions’ to SOA and ESB – ‘NZ Gov’ IdM Architectural Thinking: Five Years On

2. The Dept. of Internal Affairs is..
New Zealand Government’s leader in identity management principles and processes
Author of the NZ Identity Assurance Framework, & the NZ Evidence of Identity Standard – principles-based documents on best practice identity information management
Holder of authoritative information on New Zealand citizens – registers for births deaths, marriages, issues passports, citizenship
The home of Government Technology Services (GTS), the All of government IT initiatives – centralised Authentication and Identity Verification Services (igovt since 2007), emerging federated services, collaboration services (Public Service Intranet since 2007), centralised IP and Telephony networks (one.govt since 2009 )

3. Background: New Zealand’s culture, policy and legislation
Privacy legislation (EU-like) e.g. citizen controls use of/ release of data
No national ID or ID card, no exchange of biometrics
Low national security or illegal immigration drivers
No Inter-agency data matching excl. few exceptions
Citizen opt-in: Not compelled to use online services
Agency opt-in: Not compelled to deliver via online
Low risk, low budget approach (population: 4m)
European models – ID card with card reader – Spanish Example (traditionally have always had ID cards and unique identifiers)
US federal approach – in development, but it faces challenges of no central registries of information, everything fragmented by State. More likely that a private sector solution will be developed, e.g. out of medical, financial, given these are some of the few locations where identity information is collected nation wide – an economic (profit driven) imperative to get identity right.
India – a unique ID for every member of the country – mass take up
Puerto Rico birth certs case – High fraud in the system so voiding all issued birth certificates – and reissuing – but the process will still not eliminate fraud

4. In NZ, Identity Management is for citizen service, not national security
In contrast to countries with overriding national security issues, NZ’s Identity Management deployment is not designed for use in pursuit of national security.
National security requirements are met through existing lawful/law enforcement channels.

5. We start today’s story in 2005 but we actually started in 2002…
Policy principles before architectural design.
Cabinet approved policy principles in 2002 for authenticating people.
Security
Acceptability
Protection of privacy
All-of-government approach
Fit for purpose
Opt-in

6. Government IdP-to-government RP is different to private enterprise…
Public sector approach to Identity Management for service ≠ to Private Sector approach
Government IdP-to-government RP is different to private enterprise…
Implicit trust
Implicit (and sometimes explicit) federation
Minimal discovery – services are known
Minimal liability - Govt can’t sue itself (but citizens can use common law)
Opportunity to scale up integration

7. We set out to address 3 issues

8. The First Issue

9. The Second Issue
Keeping track of username and password for each online service is bad enough.
It will become worse when each online service moves to two-factor authentication: “Necklace of tokens.”

10. And The Third Issue
People have to use documents to establish their identity with each government agency individually   

11. So what did we do?

12. Our approach to online authentication
Two foundation services – both centralised but separate – identity and logon management
Separate who a person is (identity) - from logon management - from what they do (activity)
Decentralise authorisation and role management out to the edge

13. The Government Shared services vision
Multiple All-of-Government Services
Browser
Identity Selector/Agent Mobile Devices
Identity Providers
Any Platform
Any OS
Any IAM Solution
Any Protocol
SAML 2.0
ID-WSF
Attribute Providers
Applicable agency becomes
the authoritative source

14. In 2005 it was all about Authentication…
Shared Authentication Services
Persistent Pseudonyms
SAML 1.1 initially then SAML 2.0 in 2008

15. In 2006 it was all about Identity...
Shared Authentication Services
Persistent Pseudonyms
Identity via Browser SSO (SAML 2.0)
The Shared Authentication Services become two, with the addition of the IVS.
The Identity Verification Service (IVS) moves into Limited Service backed off (but securely separated from) the Passport Office.
Think of the Passport Office as an authoritative source of information – in this case core administrative identity information
Note the use of SSO to sign onto the GLS and IVS in order to authenticate the user - as well as verify identity – to the agency prior to authorisation and access control.
NZ participated in Liberty’s Interop in 2007 month with this approach.

16. By 2007 it was all about authoritative sources(v1.0)
Shared Authentication Services
Persistent Pseudonyms
Identity via Browser SSO (SAML 2.0)
The Shared Authentication Services expands to provide information from other authoritative sources within government (‘attribute authorities’), delivering single or joined up services

17. Enter GOAAMS…. G Government O Online A Attribute A Assertion M Meta
S System

18. …the Shared Services nirvana – GOAAMS
Shared Authentication Services
Browser
Identity Selector/Agent Mobile Devices
Identity Providers
Conclusion: A truly user centric approach..? Is it utopian? Maybe not.
Any Platform
Any OS
Any IAM Solution
Any Protocol
SAML 2.0
ID-WSF
Attribute Providers

19. …for which we won an award

20. In 2008 we began to integrate the services… and brand them

21. In 2009 we paused for thought…

22. Identity Selector/Agent Mobile Devices
No common identifier
Duplicated content
Multiple data formats
Legacy technology
Browser
Identity Selector/Agent Mobile Devices
Identity Providers
Not here
Focus was here
Attribute Providers

23. We needed a ‘perspective’ shift...
‘citizen as a customer’ – authentication and identity important for security but a by-product for folks to get the service
Shift ….from ‘agency has these information assets’
…. to ‘ citizens needs to conduct his life’ – leverage off joined-up government business cases
design for scale, not for pilots

24. Enter Service Oriented Architecture, Enterprise Service Bus and a service platform delivery model

25. Use SOA and ESB as tools to...
Retain all our privacy-aware best practice e.g. user directed consent and ‘pseudonymization’
Keep it lightweight
Business and data at the edge – in agencies
Avoid vendor product overbearance – look to fit-for-purpose open source and extend it
Build a multi-channel delivery platform, not a web portal
Design for the Cloud

26. …the old model with the new ‘SOA’ look
Service Delivery Platform
Aggregated ‘account’ view of their relationship with government
Identity Providers
SAML 2.0, WS-Trust
Semantic mapping
Internal system architecture is hidden from the Platform; each agency is treated as a ‘black box’ exposing well-defined services to the outside world via the Platform.
Agencies in roles of both Attribute Providers and Business service Providers

27. Service Delivery Platform Strawman Architecture Government Service Bus
Description
The GSB is a shared infrastructure to simplify and facilitate business transactions and service delivery between agencies.
Framework
The GSB framework may be based on one or more ESB products/frameworks.
Communication Modes
The GSB will support two modes of communication; synchronous and asynchronous:
Synchronous transactions are initiated by partner agencies’ Web Service Consumers (WSC) targeted at partner’s Web Service Provider (WSP) endpoints for real-time transactions. Most transactions including real-time user interaction will be synchronous.
Asynchronous transactions will be one of two kinds:
Publish and Subscribe data services where the publishing partner drops information on the GSB and subscribed partner(s) pull information. A variety delivery options may be available: Guaranteed delivery, receipt notification, etc..
Fire and forget business transaction exchanges mediated by a GSB orchestration component. The orchestration component would follow business rules to ensure a business transaction is correctly completed across different partners. Transactional integrity, rollback, confirmation, etc. would be managed by this component.
Data in Transit
The data transiting the GSB will have these characteristics:
Data will be in standards compliant format (CIQ, XBRL, etc.)
Cross agency semantic agreement on meaning of data on the bus
Optional data integrity/confidentiality on messages
User Identity
An user token is included in messages pertaining to an individual. There are two types of token that can be used:
Authentication tokens with the user’s Federated Logon Tag (FLT) a persistent pseudonymous identifier. This token is a SAML authentication statement created during logon service authentication and indicates that the user is participating in a transaction in real time.
“Pseudentity” token with the user’s FLT. This is a SAML token that contains only the user’s FLT and indicates that the user is not participating in real time.
Identity tokens are opaque in transit (see Data Manipulation section) and require the igovt STS map the FLT from one Identity Context to another.
Data Manipulation
An igovt STS client component will assist in mapping user FLTs between Identity Contexts for GSB transactions pertaining to an individual. When an user token is included in a message carried over the GSB, the STS client component will translate that token, using the STS, into an opaque transit token.
At the destination agency, an STS client will request that the STS decrypt the transit token and map the FLT into the destination’s Identity Context.
Each Partner Agency may need specific adaptors to translate at protocol/syntactic level between GSB and the agencies services and/or applications.
Each Partner Agency may need specific adaptors to translate data to/from agreed semantic format between the GSB and the agencies services and/or applications.
Trust
A single trust relationship between the partner agency and GSB will replace a multiplicity of trust relationships directly between agencies. Trust will be proxied between partner agencies with the GSB.
GSB Questions/Comments
Do we need to implement the consent service to maintain privacy? If so, where does it belong?
Will private sector ever play in this space? If that’s a possibility, does something need to be designed in from the outset?
There are probably a lot of sector specific data standards that need to be identified/decided.
Does there need to be a discovery service on the GSB?
Do we need asynchronous services from Day 1?
Does the Service Delivery Platform require orchestration?
Lessons learned gleaned from Burton Catalyst conference say that an ESB is more about a SOA mindset and compliance with standards than buying and installing a product/suite. It is very easy to fall into the “let’s buy one of those and job done” way of thinking.
More lessons learned… Bundled ESB suites are inflexible and generally require organisation to adapt to technology rather than the inverse. From an AoG perspective that’s probably a significant barrier.
GSB Assumptions
Some form of consent service required for Pseudonity tokens and Async services
Statefull web services not required (Fax Paradigm)

28. What agencies get from the Government Service Bus...
Service Delivery Platform Strawman Architecture
What agencies get from the Government Service Bus...
A single interface to send/receive information to other partners
Synchronous and asynchronous data services over OASIS Web Services (Stateful & REST-like)
Publish & Subscribe services
Syntax and protocol transformation & adaptation via the GSB Interface and App/Service Interface
A way to transport and transform data between agency format and standards based GSB format (semantic mapping).
An interface for each app/service published via the GSB

29. Account Linking Service – the agency ‘Club’ analogy
Service Delivery Platform Strawman Architecture
Account Linking Service – the agency ‘Club’ analogy
Description
A service that simplifies a user’s provisioning into online govt services. This service is able to:
query provisioning status of a user at partner agencies,
assert user provided information to agencies,
facilitate the collection of corroborating information from users
maintain a collective view of the user’s status and communicate that view to partners
Framework
ALS is simple IdM Workflow processor. It relies on relationships with partners and user provided information to maintain identity relationships and status. Service will be based a standard information format for representing user provisioning status (SPML?) that includes information as to associated business processes.
Central Service Requirements
Exposes WS endpoints to:
GetUsersClubStatus (pull collective view of user from ALS)
AssertUsersPartnerStatus (push provisioning status to ALS – presumably to report a status change)
Maintain each user’s collective provisioning status (as reported by partners)
Executes collectively agreed business rules to create/maintain user status in club
Does not determine provisioning status at partners (maybe execute business rules on behalf?)
Expects to talk to Partner endpoint frequently for status updates
N.B. ALS doesn’t have a UI, provided via Service Delivery Platform
Partner Requirements
Expose a common set of WS endpoints
GetUserStatus (pull user status from partner)
AssertUserInfo (push user asserted info to partner)
AssertALSInfo (push ALS summary view to partner)
Maintain relationship between local users and FLTs
Maintain information about non-ALS identity proofing / provisioning status
Provision, according to local business rules, based on information from ALS. This may include creating accounts with insufficient trust to actually deliver anything more than personalised information on the basis that trust will “accumulate” as the user interacts with service link
igovt Requirements
Expose IVS underlying services via GSB to allow user provisioning outside existing SAML process flow.
May require special treatment from STS to enable generation of conditional user tokens.
ALS Questions
How do we deal with changes to agencies identity requirements? Some of this needs to be expressed into the UI (new corroborating info?) All of this needs to be based on either easily configured or runtime parameters.
Same question for agencies with different apps/services with different requirements.
ALS will have to be delivered through the Service Delivery platform which is undefined… This leaves a pretty big, unknown requirement for connecting with that interface.
Is the push of status to the ALS required?
ALS Assumptions
ALS interactions with IVS are addressed elsewhere.

30. What agencies get from the Account Linking Service...
Service Delivery Platform Strawman Architecture
What agencies get from the Account Linking Service...
A service that simplifies a user’s provisioning into online govt services by exposing WS endpoints to ‘pull’ and ‘push’ user status and asserted user information to:
query provisioning status of a user at agencies,
assert user provided information to agencies,
facilitate the collection of corroborating information from users
maintain a collective view of the user’s status and communicate that view to partners
A Framework that offers simple IdM Workflow processing, relying on agency relationships and user provided information to maintain identity relationships and provisioning status.
igovt functionality by exposing Identity Verification services via the GSB to allow user provisioning outside existing SAML process flow.

31. What’s next?
There’s a lot to build/buy/rent - costing out a ESB/GSB & ALS without complete requirements!
Build a Security Token Service (STS) - underway
Build an Enterprise/Government Service Bus (GSB) - proposed
Build an Account Linking Service (ALS) - proposed
Build a UI for the ALS for users to change preferences
Agencies need to re-tool to be ‘SOA-like’ to join ‘the club’
We don’t yet know what we don’t know!
Continue participating in OASIS and other standardisation efforts: ‘learn-pilot-contribute’ – ‘learn-pilot-contribute’ e.g. write up as a use case for the ID-Cloud TC!

32. Thank you!