From Identity and
Authentication
‘point solutions’
to SOA and ESB –
‘NZ Gov’
IdM Architectural Thinking:
Five Years On
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
)
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)
In NZ, Identity Management is for citizen service, not national security
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
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
We set out to address 3 issues
The First Issue
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.”
And The Third Issue
• People have to use documents to establish
their identity with each government agency
individually




So what did we do?
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
The Government Shared services vision
Multiple All-of-Government Services
Browser
Identity Selector/Agent
Mobile Devices
Govt Logon
Service
Identity Providers
Idenitity
Verification
Service
Common
Online
Interface
Value
Added
Services
Govt Agency
SAML 2.0
ID-WSF
Attribute Providers
Applicable agency becomes
the authoritative source
Any Platform
Any OS
Any IAM Solution
Any Protocol
In 2005 it was all about Authentication…
Shared Authentication Services
Govt Logon
Service
Persistent
Pseudonyms
Govt Agency
SAML 1.1 initially then SAML 2.0 in 2008
In 2006 it was all about Identity...
Shared Authentication Services
Govt Logon
Service
Idenitity
Verification
Service
Persistent
Pseudonyms
Identity via Browser
SSO (SAML 2.0)
Govt Agency
By 2007 it was all about authoritative sources(v1.0)
Shared Authentication Services
Govt Logon
Service
Idenitity
Verification
Service
Persistent
Pseudonyms
Future
Services
Identity via Browser
SSO (SAML 2.0)
Govt Agency
Enter GOAAMS….
G Government
O Online
A Attribute
A Assertion
M Meta
S System
…the Shared Services nirvana – GOAAMS
Shared Authentication Services
Browser
Identity Selector/Agent
Mobile Devices
Govt Logon
Service
Identity Providers
Idenitity
Verification
Service
Value
Added
Services
Common
Online
Interface
Govt Agency
SAML 2.0
ID-WSF
Attribute Providers
Any Platform
Any OS
Any IAM Solution
Any Protocol
…for which we won an award
In 2008 we began to integrate the
services…
and brand them
In 2009 we paused for thought…
Legacy
technology
Identity Providers
No common
identifier
Duplicated
content
Multiple data
formats
Browser
Identity Selector/Agent
Mobile Devices
Govt Logon
Service
Idenitity
Verification
Service
Focus
was
here
Common
Online
Interface
Not here
Value
Added
Services
Govt Agency
Attribute Providers
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
Enter Service Oriented Architecture,
Enterprise Service Bus
and
a service platform delivery model
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-forpurpose open source and extend it
• Build a multi-channel delivery platform, not a web
portal
• Design for the Cloud
…the old model with the new ‘SOA’ look
Service Delivery Platform
Govt Logon
Service
Aggregated ‘account’
view of their
relationship with
government
Identity Providers
Idenitity
Verification
Service
Common
Online
Interface
Value
Added
Services
Govt Agency
Agencies in roles of
both Attribute
Providers and
Business service
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 welldefined services to the
outside world via the
Platform.
Government Service Bus
Service Delivery Platform Strawman Architecture
Service Platform
New Applications built around SOA principles and
standards requiring very lightweight GSB interfaces
GSB Interface
STS Client
Network/Security/Trust Interface
Identity on the GSB is made opaque by
STS Client before transiting the bus.
Identity is mapped into appropriate Identity
Context by receiving STS Client.
Data on the GSB will be represented in
Standards compliant formats; OASIS
CIQ, XBRL and other sector/context
specific standards as appropriate.
GSB
Process Orchestration
Network/Security/Trust Interface
Network/Security/Trust
Interface
Privacy/Consent
Service
STS
STS Client
GSB Interface
Identity
Verification
Service
(IVS)
STS Client
STS Client is a
proxy to STS which
generates portable
user identifying/
authenticating tokens.
Agencies: Identiful
transactions across the GSB
carry a token identifying
‘pseudonymizing’ the user.
GSB Interface
Account Linking
Service (ALS)
igovt
logon service
Identity
Context for its
users
Govt Agency
Business Business
Application Service
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
Account Linking Service –
the agency ‘Club’ analogy
Service Delivery Platform Strawman Architecture
Service Delivery Platform
Identity Context
Agencies: expose common
endpoints for user management.
ALS Client
App
SL User Status
& Preferences
- GetUserStatus(pull)
- AssertUserInfo(push)
- AssertProvStatus(push)
GSB Interface
Probably REST-like
IdM Workflow Manager
Linking
Rules
GSB Interface
ALS Client: Used by
Platform to trigger
Account Linking.
Provides proxy/pathway
to provide ALS UI.
Govt Agency 1 ...n
Identity
Context
Local User
Store
GSB
Business
Apps/
Services
Account Linking Service (ALS)
GSB Interface
IVS Service
ALS Support
Endpoints
Endpoint
Identity Verification Service
(IVS)
Identity Context
IVS: Based on self-asserted
data, “Club” status and
corroborating information,
issues an appropriate
strength igovt Id.
STS
ALS Support
Endpoint
logon service
Business
Service
Endpoints
GSB Interface
FLT Meta-Data
igovt
Agencies: assess user
information from another agency
and correlate it with their own
information on that user – after
user consent of course!
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.
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: ‘learnpilot-contribute’ – ‘learn-pilot-contribute’ e.g. write up as a use case for the ID-Cloud TC!
Thank you!
Colin.wallis@dia.govt.nz
Colin_wallis@hotmail.com