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