The deck covers what a national citizen identity and access management architecture should look like using global best practices.

1. National Target SOA Citizen Identity Architecture
Guy Huntington, President, Huntington Ventures Ltd.
September, 2016

2. 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…

3. 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)

4. • An old Burton group target architecture from
nearly 20 years ago illustrates this showing
identity, provisioning and access management
all running as web services

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

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

7. Single
Citizen
Identity
Citizen
Accesses via their phone or the internet
Government Portal
Ministry
Apps/Services
Ministry
Apps/Services
Ministry
Apps/Services
Municipalities
Apps/Services
3rd Party
Apps/Services
Crown Corp.
Apps/Services
Citizen Identity Access Management System
Identity - Foundation of e-Governance

8. National Citizen Identity Lifecycle
Citizen
Tombstone
Identity
Directory
Identity
Management
System

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

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

11. Tools To Manage Citizens’ Identities
• Identity Engine:
– Provisioning
– Workflow Engine
– Registration
– Synchronization
– Reconciliation
– Password Management
– Auditing
– Role Provisioning

12. Synchronization Auditing
Provisioning Password Management
Workflow Engine Reconciliation
Registration Role Provisioning
ForgeRock Identity – OpenIDM

13. 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
ExternalResources
Audit

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

15. Directory Requirements
• High Availability
• LDAP/Rest Interfaces
• Scalability
• Master-Master Replication

16. ForgeRock Directory– OpenDJ
LDAPv3 REST/JSON
Replication
Access
Control
Schema
Management
Caching
Auditing
Monitoring
Groups
Password
Policy
Active
Directory Sync
Reporting

17. OpenDJ Architecture
User Interface
End UserManagement
ForgeRock UI Framework
ForgeRock REST
Core Server
Replication AuditingLDAPV3Caching Monitoring
Password
Policy
Groups
Schema
Management
REST2LDAP Access Control
Backend Services
Persistence Connectors LDIF MemoryChange Log
Java SDK/ LDAPv3
Web Application
REST2LDAP
ForgeRock REST

18. Single
Citizen
Identity
Citizen
Accesses via their phone or the internet
Government Portal
Ministry
Apps/Services
Ministry
Apps/Services
Ministry
Apps/Services
Municipalities
Apps/Services
3rd Party
Apps/Services
Crown Corp.
Apps/Services
Citizen Identity Access Management System
All Apps/Services Leverage the Same
Access Management System

19. Access Management
• Provides the following services:
– Authentication
– Authorization
– Federation
– Web Services Security
– Adaptive Authentication/Strong Authentication
– Entitlements
• Must be highly available and scalable

20. ForgeRock Access Management – OpenAM
Web Services Security Session Management
Authentication Authorization
Federation Entitlements
Adaptive Risk
Single
Sign-on

21. OpenAM Architecture
ForgeRock REST (Commons REST)
Protected Resources
Web
Agents
JavaEE
Agents
Web Services
Agents
User Interface
End UserManagement
ForgeRock UI Framework
Core Services
Authentication Entitlements Session AuditngOAuth
Core Token ServiceOpenID
Connect
Configuration
Policy
User
Management
Secure Token
Service
XACML Federation
SPIs
Authentication
Plugins
Policy
Plugins
User Mgmt
Plugins
Token Service
Plugins
Federation
Plugins
Persistence
(OpenDJ)
Universal
Gateway

22. OpenAM Persistence
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ

23. OpenAM Persistence
OpenDJ
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenAM Server
Polices
Users
Configuration
Tokens
Core Services
OpenDJ

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

25. Federation Standard Protocols
OpenAM
SAML
1.0
SAML
1.x
SAML
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
OpenID
Connect
REST/JSON
SOAP
WS-
Federation 1.0

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

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

28. Mobile Apps
• Built on APIs
• Access from anywhere
• Require strong security

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

31. API Economy
API 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

32. Internet of Things Scale
Stateless Sessions
ClusterSize
Demand
Internet
Elastic Load Balancer
• Built on new
stateless sessions
• JWT-based sessions
• Per-Realm
configuration
• Enables true elastic
deployment
• Massive horizontal
scalability

33. Privacy & Consent
User 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

34. How UMA
works:
federated
authorization
on top of
OAuth
Loosely coupled to enable
centralized 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

35. The UMA
nitty gritty
Resource
owner
Resource
server
Authorization
server
Client
Authorization
API
UI
UI
UI
Requesting
party
Protection
API
Authorization
client
Protection
client
RS-specific
API
RS-specific
client
2
1
5
RPT
6
7
8
3
4
PAT
11
AAT
PAT
PAT
RPT
chooses resources to
protect – out of band
sets policies –
out of band
AAT
9
10
PAT
RS needs OAuth client credentials at AS to get PAT
C needs OAuth client credentials at AS to get AAT
All protection API calls must carry PAT
All 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 ticket
5. RS returns error 403 with as_uri and
permission ticket
6. C requests authz data, providing permission
ticket
7. (After claims-gathering flows not shown) AS
gives RPT and authz data
8. C requests resource with RPT
9. RS introspects RPT at AS (default profile)
10. AS returns token status
11. RS returns 20x

36. 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
CommonRESTAPI
CommonUserInterface
Single Integrated, Open Platform
CommonAudit/Logging
CommonScripting
• Using the identity solution open source suite- ForgeRock Platform

37. ForgeRock Commons
Simplify, 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
APIDescriptor
OpenDJ
CommonHTTP
Framework

38. 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
APIDescriptor
OpenDJ
CommonHTTP
Framework
ForgeRock UI
Mobile
Apps

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

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

41. 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
#

42. Common Audit Framework
Activity

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

45. 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…

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

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

50. 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…

52. Municipalities & Crown Corporations
• They too will leverage the same identity
• Let’s look how this will occur…

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

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

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

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

58. Protocols Used
• Identity Access Management:
– oAuth2.0
– OpenID Connect
• User Managed Access
– UMA
• JSON
• REST
• HTTPS
• XML
• BPEL

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

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

61. 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”

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

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

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

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

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

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

68. So Who’s Using This Today?
• Large companies like Toyota
• Governments including Norway, Canada, New
Zealand and Alberta
• https://www.forgerock.com/our-customers/

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