From Identity and From Identity and Authentication Authentication

‘point solutions’ ‘point solutions’ to SOA and ESB –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 )

• 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)

Background: New Zealand’s culture, policy and legislation

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

Govt Agency

Govt LogonService

The Government Shared services vision

IdenitityVerification

Service

Value Added

Services

Common Online

Interface

Multiple All-of-Government Services Browser Identity Selector/Agent Mobile Devices

Any PlatformAny OSAny IAM SolutionAny Protocol

SAML 2.0ID-WSF

Attribute Providers

Identity Providers

Applicable agency becomes

the authoritative source

Govt Agency

Govt LogonService

In 2005 it was all about Authentication… Shared Authentication Services

Persistent Pseudonyms

SAML 1.1 initially then SAML 2.0 in 2008

Govt Agency

Govt LogonService

In 2006 it was all about Identity...

IdenitityVerification

Service

Shared Authentication Services

Identity via Browser SSO (SAML 2.0)

Persistent Pseudonyms

Govt Agency

Govt LogonService

By 2007 it was all about authoritative sources(v1.0)

IdenitityVerification

Service

FutureServices

Shared Authentication Services

Identity via Browser SSO (SAML 2.0)

Persistent Pseudonyms

Enter GOAAMS….

G GovernmentO OnlineA AttributeA AssertionM MetaS System

Govt Agency

Govt LogonService

…the Shared Services nirvana – GOAAMS

IdenitityVerification

Service

Value Added

Services

Common Online

Interface

Shared Authentication Services Browser Identity Selector/Agent Mobile Devices

Any PlatformAny OSAny IAM SolutionAny Protocol

SAML 2.0ID-WSF

Attribute Providers

Identity Providers

…for which we won an award

In 2008 we began to integrate the services…

and brand them

In 2009 we paused for thought…

Govt Agency

Govt LogonService

IdenitityVerification

Service

Value Added

Services

Common Online

Interface

Browser Identity Selector/Agent Mobile Devices

Attribute Providers

Identity Providers

Legacy technology

No common identifier

Duplicated content

Multiple data formats

Focus was here

Not here

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

anda 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-for-

purpose open source and extend it• Build a multi-channel delivery platform, not a web

portal• Design for the Cloud

Govt Agency

Govt LogonService

…the old model with the new ‘SOA’ look

IdenitityVerification

Service

Value Added

Services

Common Online

Interface

Service Delivery PlatformAggregated ‘account’ view of their relationship with government

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.

SAML 2.0, WS-TrustSemantic mapping

Agencies in roles of both Attribute Providers and Business service Providers

Identity Providers

Government Service Bus

Govt Agency

GSB Interface

GSB

Network/Security/Trust Interface

BusinessApplication

BusinessServiceigovt

GSB Interface

STS

Network/Security/Trust Interface

logon serviceAccount Linking Service (ALS)

STS Client

Data on the GSB will be represented in Standards compliant formats; OASIS CIQ, XBRL and other sector/context specific standards as appropriate.

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.

Service Platform

GSB Interface

Network/Security/Trust Interface

Privacy/Consent Service

STS Client

Identity Context for its

users

Identity Verification

Service (IVS)

New Applications built around SOA principles and standards requiring very lightweight GSB interfaces

Process Orchestration

STS Client

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.

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

Service Delivery Platform Strawman Architecture

Service Delivery Platform Strawman Architecture Account Linking Service – the agency ‘Club’ analogy

igovt

Service Delivery Platform

Govt Agency 1 ...n

GSB

Agencies: expose common endpoints for user management.

- GetUserStatus(pull)- AssertUserInfo(push)- AssertProvStatus(push)

Probably REST-like

Account Linking Service (ALS)

FLT Meta-Data

SL User Status& Preferences

GSB Interface

GSB Interface

logon serviceSTSALS SupportEndpoint

IVS Service Endpoints

Identity Context

Identity Context

Local UserStore

Business Apps/

Services

Agencies: assess user information from another agency and correlate it with their own information on that user – after user consent of course!

ALS Client App

ALS Client: Used by Platform to trigger Account Linking. Provides proxy/pathway to provide ALS UI.

IVS: Based on self-asserted data, “Club” status and corroborating information, issues an appropriate strength igovt Id.

LinkingRules

GS

B Interface

ALS SupportEndpoint

GSB Interface

Business Service

Endpoints

IdM Workflow Manager

Identity Context

Identity Verification Service (IVS)

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.

Service Delivery Platform Strawman Architecture

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!

Thank you!

Colin.wallis@dia.govt.nz

Colin_wallis@hotmail.com