1 / 32

From Identity and Authentication ‘point solutions’ to SOA and ESB – ‘ NZ Gov’ IdM Architectural Thinking: Five Yea

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

betty_james
Download Presentation

From Identity and Authentication ‘point solutions’ to SOA and ESB – ‘ NZ Gov’ IdM Architectural Thinking: Five Yea

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

  4. In NZ, Identity Management is for citizen service, not national security

  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. Public sector approach to IdentityManagement 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)

  16. By 2007 it was all about authoritative sources(v1.0) Shared Authentication Services Persistent Pseudonyms Identity via Browser SSO (SAML 2.0)

  17. Enter GOAAMS…. GGovernment OOnline AAttribute AAssertion MMeta SSystem

  18. …the Shared Services nirvana – GOAAMS Shared Authentication 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

  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. 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 Busanda 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. Government Service Bus Service Delivery Platform Strawman Architecture

  28. 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

  30. 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! Colin.wallis@dia.govt.nz Colin_wallis@hotmail.com

More Related