Upload
mason-boyle
View
226
Download
1
Tags:
Embed Size (px)
Citation preview
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!