Upload
guy-huntington
View
178
Download
0
Embed Size (px)
Citation preview
National Target SOA Citizen Identity Architecture
Guy Huntington, President, Huntington Ventures Ltd.September, 2016
National Target SOA Citizen Identity Architecture
• This deck lays out a target SOA citizen identity architecture for your country
• A target architecture provides the starting framework
• The final architecture will be decided by you folks and approved by the government
• There will be additional architectures for the payment systems
• So, this is a good place to begin but not to end…
Nearly 20 Years Ago…• Many Fortune 500 companies and only a few governments realized that single
identity was a critical cornerstone piece of their digital strategies• Without this, no SOA and portal strategy would work, since having multiple
identities for the same person would not allow for seamless digital and in-person services
• Further, they also realized that having a common access service is dependent upon having a unified identity
• In my own case, at Boeing, in the early 2000’s, we implemented a unified identity and access management infrastructure and then integrated into this several large portals with more than one million users as well as 1,500 applications. In parallel, they then developed a SOA architecture based on the identity infrastructure
• An old Burton Group target architecture, from this time, illustrates this showing identity, provisioning and access management all running as SOA web services (they were the original consulting group who pioneered SOA identity services)
• An old Burton group target architecture from nearly 20 years ago illustrates this showing identity, provisioning and access management all running as web services
Estonia…
• In Estonia, in the late 1990’s they too realized that identity is the key component
• They realized that a common identity for each citizen was required
• They also realized that citizen event life triggers were also important to streamline government services
• Finally, they too also adopted a SOA web services architecture
Single Citizen Identity
• One identity per citizen• Any changes to the identity are then shared
with other apps/services consuming them– One place for a citizen to change things like
addresses and phone numbers– Citizens don’t have to fill in the same information
over and over in forms for different apps/services• Same identity used for access management
Single Citizen Identity
Citizen
Accesses via their phone or the internet
Government Portal
Ministry Apps/Services
Ministry Apps/Services
Ministry Apps/Services
MunicipalitiesApps/Services
3rd Party Apps/Services
Crown Corp.Apps/Services
Citizen Identity Access Management System
Identity - Foundation of e-Governance
National Citizen Identity Lifecycle
Citizen Tombstone
Identity Directory
Identity Management
System
Business Processes – Identity Assurance• Since the citizen’s identity is a key cornerstone of e-government services, then a
high level of identity assurance is required• When a citizen is born there needs to be:
– One or more biometrics obtained tying the citizen’s digital and physical identities together– Parent/guardian relationships in the citizen tombstone identity directory
• Most changes to the identity must be done with use of biometrics and electronic document verification– Exceptions to this might include address and telephone number changes
• These identity assurance processes are what is commonly called “identity proofing”• Identity assurance is defined in the Evidence of Identity document your
government will produce– This will be used by Government ministries, crown corporations, municipalities and third
parties to understand what the level of identity assurance is used for identities they are consuming from the central citizen tombstone identity directory
Tools To Manage Citizens’ Identities
• Citizen tombstone identity directory – LDAP– This is a “point in time” view of the citizen and
shouldn’t be authoritative for citizen identity attributes• Provisioning Database
– This records changes made to the LDAP directory from the authoritative sources
• Connectors/API’s– Used to connect the authoritative sources with the
provisioning engine which in turn then updates the LDAP directory
Tools To Manage Citizens’ Identities
• Identity Engine:– Provisioning– Workflow Engine– Registration– Synchronization– Reconciliation– Password Management– Auditing– Role Provisioning
Synchronization Auditing
Provisioning Password Management
Workflow Engine Reconciliation
Registration Role Provisioning
ForgeRock Identity – OpenIDM
OpenIDM Architecture
OSGI
MySQL, MSSQL, Postgre SQL or
Oracle Databases
ForgeRock UI Framework
ForgeRock REST Router
Business Logic (Javascript, Groovy, Java)
Authentication Filter (JASPI)
Jetty Web Server
ConfigurationManaged Users Sync/Recon System (Connectors)
Scheduler WorkflowAudit/Logs
Policy
Exte
rnal
Res
ourc
esAudit
Citizen Tombstone Identity Directory
• Uses LDAP (Lightweight Directory Access Protocol)– Specialized database using hierarchical structure– Optimized for extremely fast lookups and scalability– This is required since the LDAP directory is used for
access control, i.e. many concurrent lookups per second
Directory Requirements
• High Availability• LDAP/Rest Interfaces• Scalability• Master-Master Replication
ForgeRock Directory– OpenDJ
LDAPv3 REST/JSON
Replication Access Control
Schema Management
Caching
Auditing
Monitoring
Groups
Password Policy
Active Directory Sync
Reporting
OpenDJ ArchitectureUser Interface
End User Management
ForgeRock UI Framework
ForgeRock REST
Core Server
Replication AuditingLDAPV3 Caching Monitoring
Password Policy Groups
Schema ManagementREST2LDAP Access Control
Backend Services
Persistence Connectors LDIF MemoryChange Log
Java SDK/ LDAPv3
Web Application
REST2LDAP
ForgeRock REST
Single Citizen Identity
Citizen
Accesses via their phone or the internet
Government Portal
Ministry Apps/Services
Ministry Apps/Services
Ministry Apps/Services
MunicipalitiesApps/Services
3rd Party Apps/Services
Crown Corp.Apps/Services
Citizen Identity Access Management System
All Apps/Services Leverage the Same Access Management System
Access Management
• Provides the following services:– Authentication– Authorization– Federation– Web Services Security– Adaptive Authentication/Strong Authentication– Entitlements
• Must be highly available and scalable
ForgeRock Access Management – OpenAM
Web Services Security Session Management
Authentication Authorization
Federation Entitlements
Adaptive Risk Single Sign-on
OpenAM Architecture
ForgeRock REST (Commons REST)
Protected Resources
WebAgents
JavaEEAgents
Web ServicesAgents
User Interface
End User Management
ForgeRock UI Framework
Core Services
Authentication Entitlements Session AuditngOAuth
Core Token Service OpenID Connect Configuration
Policy User Management
Secure Token ServiceXACML Federation
SPIs
Authentication Plugins
Policy Plugins
User MgmtPlugins
Token ServicePlugins
Federation Plugins
Persistence (OpenDJ)
Universal Gateway
OpenAM Persistence
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ
OpenAM Persistence
OpenDJ
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ
OpenAM Federation
• All major federation protocols: SAML 1.x, SAML 2.0 (SP, IdP, ECP, and IdP Proxy), WS-Federation (asserting, relying party)
• Next gen-federation standards for cloud and mobile include full implementation of OpenID Connect and OAuth 2.0 (consumer, provider, authorization server).
• All Web Services security standards- Liberty ID-WSF, WS-I Basic Security Profile, WS-Trust (STS) and WS-Policy.
• FICAM (Federal Identity, Credential, and Access Management) compliant - initiative defined by the U.S. Federal Government to simplify identity and access management across government systems.
• OATH and HOTP standards that allow a mobile phone to be used as a second factor authentication.
• XACML for fine-grained authorization policy definition, import, export.• Support included for IPv6, Java 6, 7, and 8.
Federation Standard Protocols
OpenAMSAML
1.0SAML
1.xSAML
2.0
Liberty ID-FF 1.1/1.2
Shibboleth 1.0/1.1
Shibboleth 2(SAML2)
WS-Federation 1.1
ADFS
ADFS2
OAUTH 1.0 OAUTH 2.0
OpenIDConnect
REST/JSON
SOAP
WS-Federation 1.0
Credential Assurance
• Since all government ministries applications/services, crown corporations, municipalities and third parties are using the same citizen access management system, then they need to know what the credential authentication standards are
• This is spelled out in the Credential Assurance document the government will prepare
The World of API’s and Internet of Things
• Application Programming Interface (API) has become a way to rapidly implement SOA architectures and, in many cases, is replacing web services
• The use of mobile devices requires API’s • Now governments are also going to be
managing internet based “things” together with citizens
Mobile Apps• Built on APIs• Access from anywhere• Require strong security
ForgeRock API’s – OpenIG
Authentication OpenID Connect
Password Replay OAuth2
Message Transformation SAML2
Throttling Scripting
• A powerful, flexible, lean, identity centric, reverse proxy, gateway to secure all accesses to applications and APIs
API EconomyAPI Gateway
e.g. API
Client ResourceAuthN
• Secure services with standards
• Enable monetization with auditing and throttling
• Publish APIs to developers
• Integrate with any Identity Provider
Internet of Things ScaleStateless Sessions
12:00:00 AM
1:00:00 AM
2:00:00 AM
3:00:00 AM
4:00:00 AM
5:00:00 AM
6:00:00 AM
7:00:00 AM
8:00:00 AM
9:00:00 AM
10:00:00 AM
11:00:00 AM
11:59:59 AM
Demand
Clus
ter S
ize
Internet
Elastic Load Balancer
• Built on new stateless sessions
• JWT-based sessions• Per-Realm configuration• Enables true elastic
deployment• Massive horizontal
scalability
Privacy & ConsentUser Managed Access (UMA)
• Standards based privacy and consent
• Giving people the right to control access to their data across providers
• Interoperable OAuth2-based protocol
• Shipping as an integrated feature of OpenAM and OpenIG
How UMA works: federated authorization on top of OAuth
Loosely coupled to enablecentralized authorization-as-a-service for any number of an individual’s resource servers
A new concept, to enable party-to-party sharing driven by policy (or access approval) rather than requiring the individual to be present at access time
Authorization data is added to this token if trust in the requesting party is successfully elevated, typically through authentication and/or claims-gathering
The UMA nitty gritty
Resource owner
Resource server
Authorization server
Client
Authorization API
UI
UI
UI
Requesting party
ProtectionAPI
Authorization client
Protectionclient
RS-specificAPI
RS-specific client
2
1
5RPT
6
7
8
3
4
PAT
11
AAT
PAT
PAT
RPT
chooses resources toprotect – out of band
sets policies –out of band
AAT
9
10
PAT
RS needs OAuth client credentials at AS to get PATC needs OAuth client credentials at AS to get AATAll protection API calls must carry PATAll authorization API calls must carry AAT
1. RS registers resource sets and scopes (ongoing – CRUD API calls)
2. C requests resource (provisioned out of band; must be unique to RO)
3. RS registers permission (resource set and scope) for attempted access
4. AS returns permission ticket5. RS returns error 403 with as_uri and
permission ticket6. C requests authz data, providing permission
ticket7. (After claims-gathering flows not shown) AS
gives RPT and authz data8. C requests resource with RPT9. RS introspects RPT at AS (default profile)10. AS returns token status11. RS returns 20x
So Now Let’s Put It Together…
Web Services Security
Session Management Synchronization Auditing
LDAPv3 REST/JSON
Replication Access Control
Schema Management
Caching
Auditing
Monitoring
Groups
Password Policy
Active Directory Synch
Reporting
Authentication Authorization Provisioning Password Management Authentication OpenID Connect
Federation Entitlements Workflow Engine Reconciliation Password Replay OAuth2
Adaptive Risk Single Sign-on Registration Role Provisioning Message
Transformation SAML2
Throttling Scripting
Com
mon
RES
T A
PI
Com
mon
Use
r Int
erfa
ce
Single Integrated, Open Platform
Com
mon
Aud
it/Lo
ggin
g
Com
mon
Scr
iptin
g
• Using the identity solution open source suite- ForgeRock Platform
ForgeRock CommonsSimplify, Standardize App Development
Core Application Services
Common REST (CREST)
Common AuthN Framework
Commons Audit Configuration
Common Scripting
User Interface Mobile Apps
ForgeRock UI Mobile SDK
API D
escr
ipto
r
OpenDJ
Com
mon
HTT
P F
ram
ewor
k
Commons Projects• ForgeRock REST (CREST)• HTTP Framework• REST End-Point Protection (Auth Filters)• Scripting• API Descriptor• Audit• UI Framework• Self-Service
Core Application Services
Common REST (CREST)
Common AuthN Framework
Commons Audit Configuration
Common Scripting
User Interface
Mobile SDK
API D
escr
ipto
r
OpenDJ
Com
mon
HTT
P F
ram
ewor
k
ForgeRock UI
MobileApps
Scripting
Key Features– JavaScript and Groovy– JSR 223– Common HTTP Client Binding– Sandboxing– Script Registry– Debugging
Use Cases– OpenAM Authentication and
Authorization– OpenIDM Connectors and Business
Logic– OpenIG Filters and Handlers
API Descriptor
Key Features– Simple way for developers to
consume ForgeRock Common REST API.
– Descriptor allows dynamic generation of documentation, language bindings
– Pre-defined descriptors for common APIs across product
– Ability to dynamically create user interface
– Modeling capabilities that test how API responds to different options and parameters.
Audit Framework
Key Features– Multiple types of audit events– Multiple targets (audit consumers),
pluggable– Correlating events within a
transaction– Correlating events across products– Tamper evident– REST API for read and query– Client helpers– Transformation– Client context and device print
# Transaction ID
Client AuthN
Session Token
Token Store
# #
# ## #
#
access.csv activity.csv access.csv
#
Common Audit Framework
Activity
Let’s Apply This to Your Country…
• First, let’s see how the Authoritative Citizen Identity Sources can send citizen identity data via an API service to OpenIG, OpenIDM and then on to OpenDJ
Changes to the Citizen’s Identity
• The value of using this architecture is that all government ministries, crown corporations, municipalities and 3rd parties consume the same identity
• So now let’s see how an identity change then flows from OpenIDM to these entities…
Some Identity Changes May Require Citizen Consent to Send Them Out…
• In which case the architecture utilizes “User Managed Access” (UMA) which is built into both OpenIG and OpenAM
• In one place the citizen can access and manage all their digital consents for the government, crown corps, municipalities and 3rd parties
Now Let’s Add Citizens Wanting To Make A Payment to the Government
• The citizen accesses, via their cell phone or via the internet, the citizen payment portal
• The payment portal then uses a citizen identity authentication service API to OpenAM to authenticate the citizen and then…
• Passes the authenticated identity back to the payment portal which then works with the various ministry applications on the government’s network to pay for services, tickets, taxes, etc., using ewallets, SMS banking, debit and credit cards
e-Health and e-Education
• All government systems will leverage the same identity and access management system including e-Health and e-Education
• Let’s see how this would work…
Municipalities & Crown Corporations
• They too will leverage the same identity• Let’s look how this will occur…
ESB and BPEL
• The target architecture works with an Enterprise Service Bus (ESB) and Business Process Execution Language (BPEL) internally within your government
• This allows the government to:– Take the citizen’s identity and then quickly map to
identity apps, services and databases within the government for things like payment services, etc.
– Not be so reliant upon proprietary vendors where the code and business processes are not easily interfaced with
How To Securely Pass Identity Information Around Within Your Ministry and Between Ministries…
National Identity System
Internet via OpenID Connect and Encryption
Home Affairs & Labour Ministry Access Management/API
Ministry/Government Portal
Ministry Apps With Open Source Workflow Software
Government of Botswana Open Source Enterprise Service Bus
Other Ministry Applications/Services
Note: In addition to protocols already mentioned, the Ministry and the Government should be using protocols like Business Process Modeling Notation (BPMN) and Business Process Execution Language (BPEL) for Web Services to create workflows independent of vendors and/or able to integrate with vendors
Integrating Commercial Vendors Within Your Ministry To The Identity System…
National Identity System’s API
Ministry of Labour and Home Affair’s Internal Network
Internet
Home Affairs & Labour Ministry Access Management/API
Ministry/Government Portal maps PAI to the identity
Commercial app
Open Source apps
Open Source apps
BPEL/ESB BPEL/ESB
Identity Identity Identity
Moving Identity Information Around Within The Government…
National Identity System’s API
Government Internal Network
Internet via OpenID Connect
Ministry Access Management/API
Ministry/Government Portal maps PAI to the identity
Commercial app
Open Source apps
Open Source apps
BPEL/ESB BPEL/ESB
Identity Identity Identity
Protocols Used
• Identity Access Management:– oAuth2.0– OpenID Connect
• User Managed Access– UMA
• JSON• REST• HTTPS• XML• BPEL
Identity Privacy Architecture• The target architecture uses Persistent Anonymous Identifiers (PAI) to
send identities from the citizen identity directory to a portal, application or service– Example: Jane Doe’s PAI to the citizen portal might be ABCDE and for a
crown corporation it might be 123456 and for a municipality it might be ABCD1234
– This mitigates the risk if Jane’s identity information is obtained by either a man in the middle attack or, a person on the application server who gains access
– Jane Doe’s unique identity number stays within the citizen central directory and never leaves it
– Each PAI is calculated on the fly using an algorithm and is not stored in the central identity store to again mitigate risk
– Go here to learn about PAI’s-http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html
Identity Privacy Architecture
• All communication between apps/services and the central identity system is encrypted three ways:– HTTPS for the actual transmission– App/service digitally signs the transmission– The central identity service also digitally signs the
transmission• This mitigates risk of man in the middle
attacks
Identity Privacy Architecture
• No mother of all identity databases• The central citizen identity directory only has
tombstone level citizen identity information• Sensitive information such as tax numbers etc.
is stored in the pertinent ministry application and database
• This mitigates the risk of attackers wanting to get at “all the identity information in one place”
In Summary…Single Citizen Identity
• The target architecture leverages a single citizen identity
• Any changes to the identity can be pushed from the central identity service to all government ministry, municipal and crown corporation services
• Only tombstone level identity information is stored in the directory– All other sensitive identity attributes such as tax
numbers, etc. are stored in the appropriate ministry application and database
In Summary… SOA
• Different government ministry, municipal, crown corporation or 3rd party services can use an identity authentication API to call upon the citizen identity authentication service
• API’s can be easily registered and standardized by the ForgeRock architecture
• The architecture allows for secure, rapid implementation of a SOA architecture using API services
In Summary…Availability & Scalability
• The architecture is robust• It is highly available within each date centre
and between each data centre• The architecture can easily scale with
increased load• The architecture delivers high performance all
the time
In Summary…Privacy
• The architecture protects citizen privacy• No mother of all citizen databases is created• Only tombstone level citizen identity information
is stored• The citizens unique identity number never leaves
the central citizen identity directory• Persistent Anonymous Identifiers (PAI’s) are used
and are also not stored in the central citizen identity directory
• Three different encryptions used
In Summary…The Future
• The same architecture can be used in the future for additional identities:– As the internet of things develop in your country,
the architecture will easily handle increased load– Private enterprises incorporating with the
government can leverage the same infrastructure• Using the OpenIDM workflows, timelines for
incorporating a business can be significantly reduced as can renewals of business licenses, etc.
In Summary…Internet Time
• The target architecture presented is built upon the concept of internet time
• Rapid implementation of a SOA architecture is possible due to the unified ForgeRock Commons
• Developers will be given identity and API standards and can quickly implement within their applications regardless of if they are within the government, crown corporations, municipalities or 3rd parties
So Who’s Using This Today?
• Large companies like Toyota• Governments including Norway, Canada, New
Zealand and Alberta• https://www.forgerock.com/our-customers/
Suggested Tactical SOA Plan…• Like the many Fortune 500 and countries that have already long gone down
the same road that your country is likely doing regarding SOA, it makes sense to quickly get the identity architecture and infrastructure in place
• Without having single citizen identity and unified access management, the government will not be able to obtain the benefits of any citizen facing SOA architecture
• I have presented a target citizen identity architecture that is state of the art and can be quickly implemented across ministries, crown corporations, municipalities and 3rd parties by using API services
• The SOA citizen identity architecture can then be leveraged by the overall government SOA architecture, as many enterprises around the world have already done
• Significant benefits can be seen by local citizens who have only cell phones as well as those who have smartphones and internet access