realme login and realme assertion service · 2020. 2. 18. · realme login and assertion service...

UNCLASSIFIED

RealMe Login and RealMe Assertion Service

Solution Architecture Description

Solution Architecture Description RealMe Login and RealMe Assertion Service

UNCLASSIFIED Page 2 of 58

Document information

Project ID/Name RealMe Login and Assertion Service Replatforming

Author Venkat Maddali

File name RealMe Login and Assertion Service Replatforming Solution Architecture

Cohesion id

Revision history

Version Date Author Description of changes

0.1 2020-01-16 Venkat Initial draft

0.2 2020-01-24 Venkat Updated based on feedback from Team members

and TSS Architecture Practice

0.3 2020-01-31 Venkat Updated based on feedback from John Reynolds

and Phil Whipps.

1.0 2020-02-05 Venkat Ready for DIA Digital Business Governance

Approval.

Contributors

Name Role

Venkat Maddali Lead Identity Architect, Department of Internal Affairs

Adam Bradley Enterprise Architect, UNIFY Solutions

Sooraj Payyoormana IDAM Delivery Architect, UNIFY Solutions

Phil Whipps Senior Program Manager, Microsoft

Distribution list

Name Role Group

Richard Powell Senior Project Manager TSS, Department of Internal Affairs

Tim Waldron RealMe Marketing and Business

Engagement manager

SD&O, Department of Internal Affairs

Grant Stark Senior Product Advisor SD&O, Department of Internal Affairs



Name Role Group

Martin Burton Business Analyst, Project Team TSS, Department of Internal Affairs

John Crawford-Smith Manager, Business Operations SD&O, Department of Internal Affairs

Paul Chan System Support Advisor SD&O, Department of Internal Affairs

Angela Miller-Priebee Senior Systems Analyst SD&O, Department of Internal Affairs

Donna Howes Senior Product Advisor SD&O, Department of Internal Affairs

Dion Chamberlain Manager Product development TSS, Department of Internal Affairs

Mike Nelson Manager Architecture Practice TSS, Department of Internal Affairs

Liberty Fernandez Security Consultant Department of Internal Affairs

Scott Marshall Product Architect, CDOT team TSS, Department of Internal Affairs

John Keene Business Development Manager SD&O, Department of internal Affairs

Ash Brocklebank Business Development Manager SD&O, Department of internal Affairs

Phil Whipps Senior Program Manager Microsoft

Brandon Murdoch Lead Identity Architect Microsoft

Samrat Choudhury General Manager UNIFY Solutions

Leon van den Berg Project Manager UNIFY Solutions

CDOT Team Department of Internal Affairs

Preceding documents

Name Cohesion location / link

Project Mandate Mandate

Business Outcomes RealMe Login Service High Level Requirements Outcomes

RealMe Assertion Service High Level Requirements Outcomes

Business Requirements

Project Initiation Document PID on a page

Future State Approach RealMe Platform Future State Approach

https://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7b437DE837-A2AA-4AEE-BFCB-4DD5D1F92BF3%7d&file=RealMe%20replatforming%20mandate%200.2.docx&action=default&DefaultItemOpen=1https://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7bD74E6D80-5979-422E-AE8F-FE20CB78FF07%7d&file=RealMe%20Logon%20Service%20High%20Level%20Product%20outcomes%20specification.docx&action=defaulthttps://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7bA4D97D7B-0720-45D2-BA18-C3F1B17F7B7E%7d&file=RealMe%20Assertion%20Service%20High%20Level%20Product%20Outcomes%20Specification.docx&action=defaulthttps://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7bC3CB8FA4-0286-4CB2-B023-11D157AC4A53%7d&file=Logon%20migration%20PID.xlsx&action=defaulthttps://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7b15D75D36-72C2-4A81-AD48-2F2E7CEB16F4%7d&file=RealMe%20Platform%20Future%20State%20Approach.docx&action=default



References

Title Cohesion Id and link

Replatforming Security requirements Security Requirements - DIA - RealMe Replatform

Data Migration Approach Data Migration Approach

https://dia.cohesion.net.nz/Sites/PPP/PROJ/RPF/SecurityandRisk/Security%20Requirements%20-%20DIA%20-%20RealMe%20Replatform.docxhttps://dia.cohesion.net.nz/Sites/PPP/PROJ/RPF/SecurityandRisk/Security%20Requirements%20-%20DIA%20-%20RealMe%20Replatform.docxhttps://dia.cohesion.net.nz/Sites/PPP/PROG/RealMeProgramme/_layouts/15/WopiFrame.aspx?sourcedoc=%7bbb5f6890-6239-40a2-8452-60a66a005601%7d&action=default



Document submission

The Solution Architecture Description is recommended and submitted for approval.

Recommended for authorisation by Signature Date

Venkat Maddali

Product Architect, Te Ara Matihiko, DIA

Richard Powell

Senior Project Manager, Te Ara

Matihiko, DIA

John Crawford-Smith

Manager Business Services,

Service Delivery and Operations, DIA

Tim Waldron

Manager Business and Market

Development,


David Philp

General Manager Partners and

Products,


Russell Burnard

General Manager Business Operations,


Samrat Choudhury

General Manager,

UNIFY Solutions



Contents

1. Introduction 9

1.1. Document purpose 9

1.2. Solution background 9

1.3. Solution architectural scope 9

1.3.1. In architectural scope 9

1.3.2. Out of architectural scope 10

2. Business Architecture view 11

2.1. Business context 11

2.1.1. Business Problem 11

2.1.2. Business Opportunity 11

2.1.3. Business Drivers, Goals and Outcomes 12

2.2. Key Business process realisations 13

2.2.1. Customer Authentication Business Process Realisation 13

2.2.2. Customer Identity Assurance Business Process Realisation 14

2.2.3. Customer Support Business Process Realisation 15

3. Solution overview 16

3.1. Solution Principles 16

3.2. Architecture Components 17

3.3. Architectural assumptions 21

3.4. Architectural dependencies 21

3.5. Architectural risks 22

3.6. Architectural constraints 22

3.7. Architectural issues 22

3.8. Architectural goals 22

4. Logical Components view 24

4.1. RealMe Azure AD B2C 24

4.1.1. Azure AD B2C - RealMe Login Service Implementation 25

4.1.2. Azure AD B2C - RealMe Assertion Service Implementation 28

4.2. RealMe Azure PaaS Components 31

4.2.1. RealMe Front Door 31

4.2.2. RealMe Storage Account 31

4.2.3. RealMe Context Mapping Service 32

4.2.4. RealMe Extension Functions App 34

4.2.5. RealMe Insights 35

4.2.6. RealMe System Monitor 35

4.2.7. RealMe Key Vault 35



4.2.8. RealMe Health and Performance Check 35

4.2.9. RealMe Helpdesk 36

5. Solution standards 38

5.1. Standards 38

6. Technology Architecture view 39

6.1. Network architecture 39

6.2. Infrastructure architecture 39

6.3. Hosting and sites 39

7. Security view 41

8. Deployment view 47

8.1. Application Software view 47

8.2. Environments 48

8.3. Disaster Recovery, Backup and Archiving 49

8.3.1. Disaster recovery 49

8.3.2. Backup and archiving policy 51

9. Data view 52

9.1. Business data entities 52

9.2. Data archiving 52

9.3. Data migration 52

10. Architectural solution qualities 53

11. Systems Management and Monitoring 55

12. Operations Support View 56

Table of figures and tables

TABLE 1: BUSINESS CONTEXT – BUSINESS DRIVERS, BUSINESS GOALS, BUSINESS OUTCOMES MAPPING ................................................. 12

FIGURE 1: CUSTOMER AUTHENTICATION BUSINESS PROCESS REALISATION ....................................................................................... 13

FIGURE 2: CUSTOMER IDENTITY ASSURANCE BUSINESS PROCESS REALISATION ................................................................................. 14

FIGURE 3: CUSTOMER SUPPORT BUSINESS PROCESS REALISATION .................................................................................................. 15

TABLE 2: SOLUTION PRINCIPLES................................................................................................................................................ 16

FIGURE 4: AZURE ARCHITECTURE COMPONENTS HIGH LEVEL OVERVIEW ........................................................................................ 17

TABLE 3: ARCHITECTURE COMPONENTS AND INTEGRATION DEPENDENCIES ....................................................................................... 20

FIGURE 5: REALME AZURE SERVICES – LOGICAL VIEW POINT ......................................................................................................... 24

FIGURE 6: REALME LOGIN USER JOURNEY COMPONENTS INTERACTION DIAGRAM ................................. ERROR! BOOKMARK NOT DEFINED.

FIGURE 7: REALME ASSERTION SERVICE USER JOURNEY COMPONENTS INTERACTION DIAGRAM .......................................................... 30



FIGURE 8: REALME CONTEXT MAPPING SERVICE ACT ON-BEHALF OF FLOW ...................................................................................... 32

FIGURE 9: REALME SEAMLESS LOGIN COMPONENTS INTERACTION DIAGRAM ................................................................................... 34

FIGURE 10: REALME HELPDESK ACCESS ..................................................................................................................................... 36

TABLE 4: HOSTING ................................................................................................................................................................ 40

TABLE 5: REALME AZURE ENVIRONMENT - SECURITY VIEW ........................................................................................................... 46

FIGURE 11: APPLICATION SOFTWARE VIEW – PAAS AND SERVERLESS CAPABILITIES ............................................................................ 47

TABLE 6: REALME ENVIRONMENTS ........................................................................................................................................... 48

FIGURE 12: REALME BUSINESS OBJECTS .................................................................................................................................... 52

FIGURE 13: OPERATIONS SUPPORT VIEW ................................................................................................................................... 56

TABLE 7: DEFINITIONS ............................................................................................................................................................ 58



1. Introduction

1.1. Document purpose

The purpose of this document is to provide the architectural context of the proposed solution for

replatforming RealMe login service and RealMe assertion service using Microsoft Azure AD B2C,

i.e. moving from government infrastructure as a service platform to public cloud platform. This

document includes a number of architectural viewpoints which are designed to convey

architecturally significant aspects of the solution to the key stakeholders.

1.2. Solution background

The Department of Internal Affairs (DIA) is responsible for managing the RealMe login and RealMe

assertion services. The RealMe platform currently has a mixed operational support model which is

similar, but not an exact match, to the Infrastructure as a Service (IaaS) model. The existing

RealMe platform requires significant technology upgrades to be completed in the next 12 months

to remain current and maintain appropriate security levels.

Enhancing the existing platform to fix the key issues will require significant investment and could

only be recommended in an environment where appropriate alternative PaaS or SaaS options did

not exist; or the costs to transition to such a solution was prohibitive. This situation has given an

opportunity for DIA to rethink the architecture of the existing platform and implement a fit for

purpose solution for the future.

The DIA cloud adoption strategy directs services to use ‘cloud first’ where appropriate in order to

drive faster development and reduce upfront and ongoing cost. So DIA has evaluated and

confirmed Microsoft Azure B2C as an alternative PaaS/SaaS option in preference to enhancing the

existing RealMe platform.

1.3. Solution architectural scope

1.3.1. In architectural scope

The architectural scope includes:

• RealMe login service replatforming:

o Configure Microsoft Azure AD B2C as RealMe login service using customer identity

experience framework.

o DIA Staff and Agency staff access to the RealMe helpdesk portal using their

enterprise credentials.

o Support for seamless single sign-on to the RealMe helpdesk portal.

o Deploy Microsoft Azure PaaS capabilities to develop RealMe context mapping

service (RCMS), RealMe helpdesk portal and RealMe Extension Functions.

o Data migration from existing platform to Microsoft Azure AD B2C.

• RealMe assertion service replatforming:

o Configure Microsoft Azure AD B2C as RealMe assertion service using customer

identity experience framework.



• Common scope for RealMe login service and RealMe assertion service:

o Deploy Microsoft Azure PaaS capabilities to support content management, agency

integration, auditing and system monitoring functionality.

• Identify security and privacy controls to maintain and improve existing security and privacy

posture of RealMe login service and RealMe assertion service.

1.3.2. Out of architectural scope

The out of scope includes:

• Any changes to RealMe Verified Account Service functionality and current platform

• Any changes to RealMe Identity Verification Service and current platform.



2. Business Architecture view

2.1. Business context

The Department of Internal Affairs (DIA) is responsible for managing the RealMe login service. The

Login service was launched in 2007 as the Government Logon Service (GLS) and upgraded and

rebranded as RealMe login service in 2013 as part of the launch of RealMe.

The RealMe login service allows the user to securely access services online using a single username

and password. The user can use their RealMe login for both work and personal services. When the

user starts an online process that uses RealMe, they'll have the option to create a new RealMe

login or log in if they already have an existing RealMe login. The RealMe login service currently

has more than 4 million user login accounts and more than 130 agency services have integrated

with the service.

DIA has developed addition capabilities under the RealMe brand; the RealMe verified account and

the RealMe assertion services. The RealMe assertion service allows the user to share their verified

account (identity and address) details to the wide range of public and private sector online

services. Currently there are more than 700k RealMe verified accounts created and more than 24

services have integrated with the RealMe assertion service.

2.1.1. Business Problem

The current state of the RealMe platform lacks flexibility, scalability and does not meet new

security requirements and is financially unstainable for department and NZ government. Below

are the key issues with the current state:

• DIA has been spending high operational cost for network, storage, server and application

support management functions. This is expensive when compared with the solutions

offered by PaaS/SaaS providers in the market.

• Any customer experience enhancements and new functionality requires significant

development effort because most of the RealMe code is custom.

• The current architecture of the RealMe platform requires a lot of planning, management and co-ordination for platform upgrades, and sometimes platform capabilities must be purchased on extended support licenses.

• DIA is unable to respond rapidly to the changing requirements for RealMe as every new piece of functionality requires custom code development.

• DIA is unable to meet evolving security requirements such as risk profiling, security event

information management etc.

2.1.2. Business Opportunity

The RealMe platform requires significant technology upgrades to be completed in the next 12

months to remain current and maintain appropriate security levels. This requirement gives the

opportunity for DIA to rethink the architecture of the existing platform and implement a fit for

purpose solution for the future.



In recent years the customer digital identity and access management (CIAM) solution space in

market has matured significantly. Many leading vendors are offering CIAM solutions through

Software as a Service (SaaS) or Platform as a Service (PaaS) models that should provide a better

way forward for the RealMe Platform. DIA has evaluated and confirmed Microsoft Azure B2C as an

alternative PaaS/SaaS option in preference to enhancing the existing RealMe platform

2.1.3. Business Drivers, Goals and Outcomes

Below are the key business drivers, business goals and business outcomes applicable for the architecture are:

Business Driver Business Goals Business Outcomes

Financial Sustainability

Any investment in RealMe

capability is financially

sustainable and operates with

a well-defined business

model.

Optimise cost and investment

across NZ government

Optimised cost to develop

and operate RealMe services

for NZ government

Fit for Future


capability meets

requirements of the users

and service providers.

Provide Fit for Future

Authentication

Simplified access to digital

services by customers offered

by government.

Continued reduction in effort

and investment by individual

agencies to manage and

support logins in siloed

environments.

Digital services demand


capability supports needs of

the digital services.

Rapidly respond to the digital

services needs

Developed partnership with

Microsoft to meet digital

service’s needs (i.e. risk based

authentication, different MFA

options, support for self-

sovereign models).

Citizens participating in digital

services provided by NZ Inc.

Trust

Any investment in digital

identity capability enhances

trust and increase all parties

participating in digital

economy.

Maintain trust with relying

parties and customers

Appropriate security controls

in place to maintain identity

services integrity.

Table 1: Business Context – Business Drivers, Business Goals, Business Outcomes mapping



2.2. Key Business process realisations

2.2.1. Customer Authentication Business Process Realisation

Figure 1: Customer Authentication Business Process Realisation

Department of Internal Affairs (DIA) is the provider of Digital Authentication business service to

the public sector agencies, play the role of “Service Provider”. The Digital Authentication business

service is realised through the Customer Authentication business process. NZ Public play a role of

“Service User”, participate in the Customer Authentication business process.

The RealMe Login application service implements the Customer Authentication business process.

The Azure AD B2C component of the RealMe Login service provides the RealMe Login SAML IdP

WebSSO interface for the “Service Provider” to enable the Customer Authentication business

process to the public sector agency services.



2.2.2. Customer Identity Assurance Business Process Realisation

Figure 2: Customer Identity Assurance business process realisation

Department of Internal Affairs (DIA) is provider of Digital Identity Assurance business service to

the public sector and private sector agencies, play a role of “Service Provider”. The Digital Identity

Assurance business service is realised through the Customer Authentication business process. NZ

Public play a role of “Service User” participate in the Customer Identity Assurance business

process.

The RealMe Assertion application service implements the Customer Identity Assurance business

process. The Azure AD B2C component of the RealMe Assertion service provides RealMe

Assertion SAML IdP WebSSO interface for the “Service Provider” to enable the Customer Identity

Assurance business process to the public sector and private sector agency services.



The Azure AD B2C component interacts with the external services (Identity Verification service,

Address Verification service and consent service) through APIs to support the Customer Identity

Assurance business process.

2.2.3. Customer Support Business Process Realisation

Figure 3: Customer Support Business Process Realisation

DIA Contact Centre and Agency Contact Centre helpdesk operators are assigned to the Customer

Support business process. The RealMe Helpdesk application service implements the Customer

Support business process. Azure AD B2C acts as an access point for providing helpdesk operator’s

access to the RealMe helpdesk web app.

UNCLASSIFIED

3. Solution overview

3.1. Solution Principles

Principle Description

1 SaaS First SaaS first then PaaS where appropriate to minimise

customisation.

2 Security Suitable protection must be provided at all levels from

design to implementation to operation.

3 Protection of privacy Ensuring that the proposed authentication approach protects

privacy appropriately.

4 Fit for purpose Avoiding over-engineering, recognising that the levels of

authentication required for the government digital services to

people will be relatively low.

5 Fit for future Supporting the levels of authentication required for future

needs of the government digital services and people.

6 Acceptability Ensuring that the proposed authentication approach is

generally acceptable to people, considering the different

needs of people and emerging industry standards, and

avoiding creating barriers.

7 Customer focus Ensuring the recommended authentication methods are

convenient and easy to use.

8 All of Government Balancing people and government agencies' concerns about

independence with the benefits of standardisation while

delivering a cost-effective authentication solution.

9 Endurability Enduring solution Providing an authentication solution that is

enduring yet sufficiently flexible to accommodate change

and a wide range of current and future transactions.

10 Affordability and reliability Ensuring the recommended solutions are affordable and

reliable for the people and government agencies.

11 Non-repudiation The issue of non-repudiation must be considered, so that

the risk of transacting parties later denying having

participated in a transaction is minimised.

12 Simple client Integration Standardised interfaces for the simplest means possible of

integrating agencies.

13 API First Where appropriate provide services through APIs.

14 Accessibility Making sure everyone can access RealMe services.

Table 2: Solution Principles

UNCLASSIFIED

3.2. Architecture Components

NZ Public

Relying parties

MSDMBIE IR OthersDIA Banks

RealMe Login Service RealMe Assertion

ServiceAzure AD B2C

SAMLv2.0

WebSSO EndpointSAMLv2.0

WebSSO Endpoint

RealMeCredentials Store

Graph API

RealMe Front Door

RealMe

Insights

RealMe System MonitorRealMe Helpdesk

Webapp RealMe Storage Account

RealMe Extension Functions App

RealMe Key Vault

DIA - Microsoft Azure Tenancy RealMe Resource Group

RealMe Context Mapping Service

RealMe Azure Resources

Identity Verification Service Address Verification ServiceRealMe Consent Service

External Integration

RealMe AnalyticsAzure AD B2C

RealMe Helpdesk Federation Hub

SAMLv2.0IdP initiated

SSO

RealMe Health and

Performance Check

MB

IED

IAIR

MSD

Age

ncy Se

rvice Desk

Service Desk Operators

Access throughAgency Login

HD Access

Figure 4: Azure Architecture Components High Level Overview

The following table provides architecture components integration dependencies:

Architecture

Component

Technology Integration & Dependencies Comments

RealMe Login Service

Azure AD B2C Integration with Azure Front Door

for below RealMe Azure

resources:

• RealMe Extension Functions App

• RealMe insights

Azure AD B2C provides

SAMLv2.0 endpoint for the

relying parties to

authenticate the user.

The Azure AD B2C has a

directory to store user

credentials and associated

FLTs.



Architecture

Component


RealMe Assertion

Service

Azure AD B2C Integration with Azure Front Door

for below RealMe Azure

resources:


• RealMe insights

• RealMe Context Mapping Service API

Azure AD B2C provides

SAMLv2.0 endpoint for the

relying parties to integrate to

allow the user to share their

verified identity and address

attributes.

RealMe Front Door Azure Front

Door

Integration with below RealMe

Azure resources:

• Helpdesk Web app

• RealMe insights

• RealMe Context Mapping Service


• RealMe Storage Account

RealMe Front Door Service is

Microsoft's highly available

and scalable web application

acceleration platform and

global HTTP(s) load balancer.

RealMe Storage

Account

Azure

Storage

RealMe storage account

provides storage containers

for persisting non user

specific data.

RealMe Helpdesk

Federation Hub

Azure AD B2C RealMe helpdesk web app

through RealMe Front Door

The RealMe Helpdesk

Federation Hub provides

SAMLv2.0 SP endpoint to

allow agencies to initiate

seamless single sign-on from

their enterprise to the

RealMe helpdesk web

application.

RealMe Helpdesk

Web App

Azure Web

App

RealMe Insights

Azure AD B2C Graph API


The DIA service desk and

agency service desk staff uses

RealMe helpdesk web app to

support the customer.



Architecture

Component


RealMe Extension

Functions App

Azure

Functions

App

RealMe Insights


RealMe Consent Service

Identity Verification Service

Address Verification Service

RealMe extension functions

app provides extension

functions to support login

and assertion user journeys.

RealMe Context

Mapping Service

(RCMS)

Azure Web

API


RealMe Insights


RealMe Context Mapping

service is fundamental

privacy by design

architecture component to

support RealMe assertion

user journey and cross

agency user journeys.

RealMe Insights Azure

Application

Insights

All architecture components All architecture components

integrate with the RealMe

insights to provide system

level, application level and

user activity logging.

RealMe System

Monitor

Azure

Monitor

RealMe Insights This component monitors

and alerts RealMe

architecture components.

RealMe Analytics Web

Application

RealMe Insights UNIFYMonitor provides

various dashboards on User

Experience and various

performance metrics of the

RealMe architecture

components.



Architecture

Component


RealMe Key Vault Azure Key

Vault

RealMe Key Vault persists

RealMe Azure resources keys

and certificates. RealMe

Context Mapping Service,

RealMe Extension Functions

App and RealMe Helpdesk

Web App integrate with

RealMe Key Vault for

certificates and symmetric

keys.

RealMe Health and

Performance Check

Azure Web

App

RealMe Login Service

RealMe Assertion Service

RealMe System Monitor

This component has two

objectives:

• Health Check of RealMe

services

In case of any issues related

user journey this component

notifies RealMe System

Monitor to initiate alerts to the

RealMe services managed

team.

• Performance Testing

ITE performance testing to

confirm that the services have

met SLA.

Table 3: Architecture Components and Integration dependencies

UNCLASSIFIED

3.3. Architectural assumptions

Below are the key architecture assumptions:

• The RealMe replatforming solution shall not change most of current RealMe login service

and RealMe assertion service functionality.

• The current RealMe login web services, igovt Context Mapping Service (iCMS), Helpdesk

Web Service and Contact Details Web Service will be decommissioned and replaced with

APIs. Impact on any existing services will be handled through agency engagement stream.

• There shall be minor user interface changes to the customer facing flows, especially

manage login page.

• The RealMe helpdesk web application user interface and authentication method shall

change from the current web application and is acceptable to DIA and agencies.

• The existing RealMe login and assertion services code would not be migrated to the Azure

AD B2C and is acceptable to DIA.

• All the current and new agency integrations shall be handled through new RealMe Azure

platform. The current RealMe platform doesn’t need to manage any agency integrations

after RealMe re-platforming to Azure AD B2C because the agencies will be integrated with

Azure AD B2C platform.

3.4. Architectural dependencies

Azure Tenancy / Account

• The Azure AD B2C and Azure PaaS capabilities required for RealMe re-platforming shall be

deployed under DIA Azure Tenancy/ Account. A new resource group shall be created for

RealMe capabilities for test and production environments. DIA CDOT team is responsible

for setting up resource group, Azure AD B2C and Azure PaaS capabilities for RCMS,

Helpdesk Web App, Extension Functions App etc.

• Azure DevOps shall be used for the project and operational lifecycle management. A new

project for RealMe shall be created under service delivery operations organisation in Azure

DevOps.

Helpdesk Access

• DIA Staff shall access helpdesk web application using their DIA credentials as per DIA

Identity and Access Management (IAM) strategy. The helpdesk web application shall be

federated using DIA Azure AD. DIA CDOT team is responsible for enabling Azure AD

federation for Helpdesk web application.

Identity Attribute Provider Integration

• Azure AD B2C (RealMe assertion service) shall directly integrate with the Identity

Verification Service (IVS) for RealMe verified identity details.



• Azure AD B2C (RealMe assertion service) shall directly integrate with the Address

Verification Service (AVS) for verified address details.

RealMe Consent Service APIs Integration

• Azure AD B2C (RealMe assertion service) is required to integrate with the RealMe consent

service APIs. These APIs are required to be deployed on the current RealMe platform.

3.5. Architectural risks

Below are the key risks identified to the architecture:

• Any Azure AD B2C defects may drive towards custom code path to suppress the defects.

• Azure AD B2C may not be available in Australia datacenter before production go-live date.

• The business requirements may drive towards custom code as Azure AD B2C may not

support out of the box.

3.6. Architectural constraints

The key architectural constraints on the solution are:

• The solution shall use Azure AD B2C functional capabilities and avoid custom code path to implement business requirements.

• The solution must support the current RealMe login service and RealMe assertion service message specifications.

• The solution must comply with the New Zealand Privacy Act 1993. The solution must work within the privacy principles defined within the NZ Privacy Act.

• The solution must provide suitable protection for data in transit and at rest.

• The solution shall follow open and widely adopted standards.

• The solution shall maintain appropriate authentication levels to access functionality.

3.7. Architectural issues

There are no major issues identified with the architecture.

3.8. Architectural goals

Below are the key architecture goals:

• Flexibility/Scalability

o Services are highly available, and the functionality can be accessed from anywhere.

o Rapid delivery of new capabilities using Azure B2C.

o The customer peak/non-peak periods can be better managed using Azure B2C.

• Reliability



o Seamless, on-time upgrades to operating system, network, middleware components including version management.

o Data replicated on back-up servers more regularly (Recovery Transfer Objective – 60 mins, Recovery Point Objective – 0 mins).

• Agility

o Rapid enablement of new functionality through low code or no code options

o Shorter deployment times due to support various deployment tools.

• Security

o Future state advanced security protection and conditional access including detection and reporting of risk based profiling.

o Security information event monitoring and management.

• Operational and Development Cost Reduction

o Reduced infrastructure footprint - nothing to buy or maintain in terms of operating system, networks or middleware components.

o Eliminate upfront commitment to technology components and products.

o Avoid the need to commit investment for future roadmap items as the SaaS/PaaS provider will develop and improve the product based on its world-wide customer base and competitive drive operating in an international market.

o Avoids capital charge and depreciation



4. Logical Components view

Login User Journeys

DIA - Microsoft Azure Tenancy

RealMe Login SAML IdP Endpoint

Seamless Login

Login/ Create Login

Identity Experience Frame Work

RealMe Key Store

RealMeCredentials Store

Manage Login Multi-Factor

Authentication

Relying Party Configuration

Assertion User Journeys

Assert


Assert and Login

RealMe Assertion SAML IdP Endpoint

Email Notification

Resource Owner Password Credential

OAuth2.0 Token Endpoint(LAT Issuer)

SAMLv2.0 SPAzure AD B2CAzure AD B2C


RealMe Helpdesk

Webapp

Agency IdP Metadata

Configuration

UI

Store

RealMe

Insights


SAML Artifact Resolve Service

Access to:

RCMS and Attribute Provider Integration, UI, App Insights

Get Identity Attributes



Verified Identity APIs

Address Retrieval APIs

Identity Verification Service Address Verification Service

Consent APIs


Relying parties

MSDMBIE IR OthersDIA Banks

Access to SAML Artifact Service

HD OperatorsCredentials Store

Agency Config Retrieval

TOTP Reg & Validation

Agency Service Desk

MBIEDIA IR MSD

RealMe Resource Group

RealMe System Monitor

RealMe Analytics

RealMe Context Mapping Service (RCMS)

Agency Config Table Store

SP Metadata

Store

RealMe Storage Account

Graph API

RealMe Front Door

Get Contact Details

support assertionjourney

Access to:RCMSCD API

Access to : App insights

Logs

Access to HD Portal

Artifact Response

Store

RealMe Key Vault

RealMe Health and

Performance Check

FLT Generation and Retrieval

Figure 5: RealMe Azure Services – Logical View Point

4.1. RealMe Azure AD B2C

Azure Active Directory B2C (Azure AD B2C) is a customer identity access management (CIAM)

solution capable of supporting millions of users and authentications per day. It takes care of the

scaling and safety of the authentication platform, monitoring and automatically handling threats

like denial-of-service, password spray, or brute force attacks.

Azure AD B2C is built on the Azure Active Directory (Azure AD) identity platform, which supports

different identity segments such as enterprise users, partners etc. Azure AD B2C gives the

scalability and availability that RealMe services need.

Azure AD B2C support industry standard federation protocols such as Security Assertion Mark-up

Language (SAML), OpenID Connect and OAuth2.0.

Note: Refer to https://docs.microsoft.com/en-us/azure/active-directory-b2c/technical-overview

for Azure AD B2C technical overview.

https://docs.microsoft.com/en-us/azure/active-directory-b2c/technical-overview



RealMe Brand

Azure AD B2C is a white-label identity solution that can be configured and customised the entire user experience with RealMe brand when users sign up, sign in, and modify their profile information. The HTML, CSS, and JavaScript can be customised in RealMe user journeys so that the Azure AD B2C experience looks and feels like it's a native part of RealMe services.

Identity Experience Framework

The extensible policy framework of Azure AD B2C is its core strength. Policies describe your users' identity experiences such as sign up, sign in, and profile editing.

In Azure AD B2C, there are two primary paths to provide the identity experiences:

• User flows - user flows are predefined, built-in, configurable policies that can create sign-up, sign-in, and policy editing experiences in minutes.

• Identity Experience Framework policies - enable the creation of RealMe specific user journeys for complex identity experience scenarios.

Both user flows and Identity Experience Framework policies are powered by the Identity Experience Framework, Azure AD B2C's policy orchestration engine.

4.1.1. Azure AD B2C - RealMe Login Service Implementation

User Journey

The RealMe login service user journeys are configured through custom policies. The Identity Experience Framework gives the ability to construct below RealMe login service user journeys:

• Login/ Create Login

• Multifactor Authentication

• Manage Login

• Recover username

• Change/Reset password

• Login step-up

• Seamless login

User Directory

The Azure AD B2C has its own Azure AD instance. The RealMe user details are stored in the Azure AD user directory and encrypted at rest. The RealMe user directory contains:

• Username/

• Password hash/ hash algorithm

• Email address, secondary email address

• Contact number



• SMS number

• Security questions

• Secret PIN

• TOTP Key for Authenticator app

• Federated Login Tags (FLT) for issued for the relying party privacy domains.

Multifactor Authentication

Azure AD B2C currently supports SMS and Phone call back as second factor authentication methods. TOTP based authentication support is a roadmap item and should be available in year 2020. A custom function is created to support TOTP based second factor authentication method.

Auditing and Logging

The system transaction and user audit logs are saved in RealMe app insights as Azure AD B2C currently can persist them for a limited period.

Relying Party Integration

Azure AD B2C provides SAMLv2.0 endpoints for the relying parties to integrate with the RealMe

login service user journey. On successful authentication the RealMe login service issues SAML

Assertion to the relying party service. The SAML Assertion includes the user’s FLT for the relying

party service, authentication strength, authentication time etc. No other personal attributes are

shared with the relying party service.

Implementation of Privacy Framework:

The RealMe login service privacy framework is underpinned by the concept of privacy domain. A

privacy domain is an isolated personal information vault where no cross-referenceable identifiers

are shared with other privacy domains. This means the information in one privacy domain cannot

be used to understand or correlate information residing in another privacy domain.

The privacy domain model is underpinned by the ability of the RealMe login service to provide a

mutually exclusive set of identifiers, or federated login tags (FLTs), to these privacy domains.

Explicitly, this means that a FLT used in one privacy domain is never re-used in another privacy

domain, so each privacy domain always operates in effective federated isolation from all other

privacy domains.

Only the RealMe login service (the RealMe identity provider) has visibility of the unique identifier

for each privacy domain, and it can only issue an identifier to a privacy domain if that privacy

domain owns the identifier. The result of this design is that data cannot be linked between

different privacy domains without intermediation by the RealMe login service.

The user’s FLT is generated, persisted against the relying party privacy domain in Azure AD B2C user directory as an extension attribute through RealMe extension functions app and shared with the relying party service based on the user successful authentication.



Login Attribute Token Issuance

As per current design relying party services such as RealMe verified account service require Login Attribute Token (LAT) to interact with the RealMe context mapping service. OAuth2.0 Resource Owner Password Credential is configured in Azure AD B2C to issue Login Attribute Token to the relying party service.

RealMe Azure Resources Integration

The RealMe login user journeys require below RealMe Azure components integration through RealMe Front Door, see Figure 6 below:

• UI Store: for login pages including stylesheets and java script.

• SP Metadata Store: for retrieving the requested relying party service’s SAML SP metadata file to validate the relying party service request and identifying the relying party preferred SAML response binding to issue SAML response to the relying party service.

• Agency Config Retrieval Function: for displaying the relaying party service co-branding details on the login pages.

• TOTP Reg & Validation Function: for supporting TOTP based second factor authentication method using Authenticator app.

• FLT Generation and Retrieval Function – Azure AD B2C can generate pseudonymous identifier for relying party through custom policy but doesn’t persist in the user directory. So Azure AD B2C invokes this function to generate FLT, save it in user directory and retrieve it on successful user authentication for relying party.

• RealMe Insights: for persisting RealMe login service system logging and user auditing.

RealMe Login Journey – components Interaction Diagram (SAMLv2.0 POST Binding)

Azure AD B2C

RealMe

Login User Journeys

RealMe Login SAML IdP Endpoint

Login/ Create Login

UI

Store

Agency Config

Table StoreSP Metadata

Store


RealMe Front Door



User

Relying Party1. Login

2. SAML Authn Request

7. Log to App Insights (Asynchronous)

3.1 get Login Page, SP Metadata File

3.2. Get Agency Config

4. Login Page andSubmits Credentials

RealMe

Insights

5. Get FLT

6.1 User and System Activity Log

6. SAML Response

Graph API

FLT Generation and Retrieval

5.1 Get User Details including FLT

3. Get Login Page, SP Metadata File, Agency Config details



4.1.2. Azure AD B2C - RealMe Assertion Service Implementation

The RealMe assertion service is configured as a pass-through service in Azure AD B2C and doesn’t save any user details in the RealMe credential store. The RealMe assertion service is configured as an orchestration engine using Azure AD B2C Identity Experience Framework to implement below steps involved in the RealMe assertion process:

• Login

• Get Identity Attributes from Identity Attribute Providers (IVS, AVS)

• User consented attributes sharing with the relying party service

The RealMe assertion service login mechanism changes from current state communication method (i.e. SAML federation) between the RealMe assertion service integration with RealMe login service. Both RealMe login service and RealMe assertion services are configured in the same instance of the Azure AD B2C, the RealMe assertion service user journeys can reuse the login service user journey to authenticate the user. This approach simplifies the RealMe assertion service implementation and improves the customer experience due to a reduction in the number of redirects. But there is no change to the RealMe privacy posture with this approach as RealMe assertion service is pass-through service and doesn’t persist any customer verified data.

User Journey

Below RealMe assertion service user journeys are configured through the Identity Experience Framework:

• Assert – user consented attribute sharing with the relying party service

• Assert and Login - user consented attributes and login token sharing with the relying party service.

User Directory

The user’s verified identity details are not saved in RealMe credential user store.

Auditing and Logging

The system transaction and user audit logs are saved in RealMe app insights as Azure AD B2C currently can persist the logs for a limited period.

Relying Party Integration

Azure AD B2C provides SAMLv2.0 endpoint for the relying parties to integrate with the RealMe

assertion service user journey. On successful authentication the RealMe assertion user journey

interacts with the identity attribute providers (IVS, AVS) to retrieve user’s attributes and shares

user consented attributes with the relying party service. In assert and login user journey, the

RealMe assertion service shares user consented attributes and login token with the relying party

service.



RealMe Azure Resources Integration

The RealMe assertion user journeys require below RealMe Azure components integration through RealMe Front Door (see below Figure 7):

• UI Store: for login and consent pages including stylesheets and java script.

• SP Metadata Store: for retrieving the requested relying party service’s SAML SP metadata file to validate the relying party service request and identifying the relying party preferred SAML response binding to issue SAML response to the relying party service.

• Agency Config Retrieval Function: for displaying the relaying party service co-branding details on the login and assertion pages.

• TOTP Reg & Validation Function: for supporting TOTP based second factor authentication method using Authenticator app.

• RealMe Context Mapping Service API – to obtain user tokens to interact with the external sources, RealMe consent service, Identity verification service, Address verification service.

• Get Identity Attributes Function – to retrieve identity attributes from the identity attribute providers (IVS, AVS) and to retrieve consent sharing terms and existing user’s consents from the RealMe consent service.

• RealMe Insights: for persisting RealMe login service system logging and user auditing.

RealMe Assertion Journey – components Interaction Diagram (SAMLv2.0 POST Binding)



Login User Journeys

Login/ Create Login


Assertion User Journeys

Assert


Assert and Login

RealMe Assertion SAML IdP Endpoint


OAuth2.0 Token Endpoint(LAT Issuer)

Azure AD B2C

UI

Store

RealMe

Insights


5. Get Opaque Tokens for Consent, IVS or AVS

Get Identity Attributes



Verified Identity APIs

Address Retrieval APIs

Identity Verification Service Address Verification Service

Consent APIs


Relying Party

2. SAML Request



Agency Config Table Store

SP Metadata

Store


3.1 Get UI pages, Agency Config

3.2. Get Agency Config

6.1. get Attributes for opaque tokens

5.1 Issue Opaque Tokens

Graph API

RealMe Front Door

3. Get Login Page, Agency Config, Metadata File

6.2 Get Consent, IVS, AVS

User

1. Start

4. Display Login Page andSubmits Credentials

5.2 Get FLT for IVS, AVS, Consent Service


6. get Attributes for Opaque Tokens

7. Display Consent Page and gives Consent

8. SAML Response (Attributes)

RealMe

9. Notify Consent and Log System and User Activity ( Asynchronous)

Figure 6: RealMe Assertion Service User Journey Components Interaction Diagram



4.2. RealMe Azure PaaS Components

4.2.1. RealMe Front Door

RealMe Front Door Service is Microsoft's highly available and scalable web application acceleration platform and global HTTP(s) load balancer.

Below are some of key scenarios that RealMe Front Door Service addresses:

• improves application scale and availability with instant multi-region failover.

• improves application performance with SSL offload and routing requests to the fastest available RealMe resources at the backend.

• application layer security and DDoS protection for RealMe backend resources.

Note: refer to https://azure.microsoft.com/en-us/services/frontdoor/ for technical overview of Azure Front Door.

4.2.2. RealMe Storage Account

RealMe storage account provides storage containers to save user interface related files, SAML SP metadata files, agency co-branding details and helpdesk config details. Below stores are configured under RealMe Store Account:

• UI store

UI store is configured using Azure Blob Storage. UI store persists RealMe login and assertion service user interface related files such as HTML, style sheets, images, java scripts etc. UI store provides an API to allow Azure AD B2C to retrieve user interface files to support login and assertion journeys.

• SP Metadata Store

SP Metadata Store is configured using Azure Blob Storage. SP Metadata Store persists the relying party’s SP metadata files. SP Metadata Store provides an API to allow Azure AD B2C to retrieve relying party’s SP metadata file1 to support login and assertion journeys.

• Agency Config Store

Agency Config Store is configured using Azure Table Storage. Agency Config Store persists agency co-branding details such as images and text and agency helpdesk configuration details.

• Artifact Response Store

Artifact Response Store is configured using Azure Blob Storage. Artifact Response Store persists the relating party’s Artifact SAML response. Artifact Response Store provides an API to allow relying party services to retrieve SAML response for SAML Artifact. This is only

1 Where it is not available from service provider metadata endpoint URL

https://azure.microsoft.com/en-us/services/frontdoor/



required for legacy RealMe Integrations that require SAML Artifact Binding, and that these will slowly be migrated to POST binding.

4.2.3. RealMe Context Mapping Service

RealMe Context Mapping Service is a restful Security Token Service (STS), a service capable of

validating security tokens provided to it and issuing new security tokens in response, which

enables relying party services to obtain appropriate access credentials for resources in

heterogeneous environments or across privacy domains.

The RealMe Context Mapping Service (RCMS) issues a security token to the service by mapping a user’s authentication context from one service privacy domain (FLTSP) to other service privacy domain (FLTosp), which enables the service to access appropriate user information from the other service through APIs.

Below are two key uses:

• It will allow the customer to exchange their data between the integrated services across privacy domains without the provision of a single identifier;

• Seamlessly navigate between services in different privacy domains.

The RealMe Context Mapping Service is implementation of OAuth2.0 token exchange profile act

on-behalf of flow. It is currently roadmap item for Azure AD B2C and will be available in later part

of year 2020. So RCMS is developed using .Net custom code and deployed as Azure web API.

Act On-behalf Flow

Azure AD B2C

Graph API

RealMe Front Door


Service

Privacy Domain 1

2. Request for security token 3. request forward

4. Get User details for FLT of service


5. Issue Opaque token

6. Opaque token

Other Service

Privacy Domain 2

7. Resource request for Opaque token

8. response

RealMe

User

1. initiates cross privacy domain transaction

Figure 7: RealMe Context Mapping Service act on-behalf of flow



Key points regarding RCMS act on-behalf of flow:

• The user initiates cross privacy domain transaction at relying party service. The user is

already authenticated by the RealMe Login service at the relying party service.

• Relying party service in one privacy domain requests a security token from the RealMe

Context Mapping Service through RealMe Front Door. The request contains Login

Attribute security token (LAT), the service receives on successful user authentication and

other service identifier.

• The RealMe Context Mapping Service validates login attribute security token and invokes

the Azure AD Graph API with the service user identifier (FLTSP). The Azure AD Graph API

returns user details which also includes FLT of other service. If the user’s FLT for the other

service is not found, then creates an FLT and updates the user object with FLT through

Azure AD Graph API.

• The RealMe Context Mapping Service creates a security token (i.e. JWT) with FLT of other

service and encrypts security token using other service’s encryption certificate. The

encrypted security token is known as opaque token. The opaque token is returned in the

response to the service.

• The service invokes the other service API with the opaque token. The other service

decrypts the opaque token, identifies the user based on FLT and returns user information

in response. If the user record is not found for an FLT, then other service can initiate user

register process.

Seamless Login Flow

The RealMe context mapping service also provides Seamless Login end point for the user to

seamlessly navigate from one privacy domain to other privacy domain. Below diagram provides

components interaction for the user seamless login from one privacy domain service to other

privacy domain service.



Azure AD B2C

Graph API

RealMe Front Door


Service

Privacy Domain 12. Request for seamless

security token 3. request forward

4. Get User details for FLT


5. Issue Opaque token

6. Opaque token

Other Service

Privacy Domain 2

7. Redirect with Opaque Token, Relay state parameters

RealMe

Seamless Login

Endpoint

9. Trigger IdP Initiated SSO

10. SAML Response

SAMLv2.0 IdP EndpointOIDC Authorisation Server

8. Initiate user statethrough opaque token

User

1. Clicks link to navigate to Other service

Figure 8: RealMe Seamless Login Components Interaction Diagram

Below are the key Integration dependencies for RealMe Context Mapping Service:

• Azure AD Graph API: for retrieving user details and updating user details with new FLT.

• Agency Config Retrieval Function: for retrieving the relaying party service encryption certificate.

• Azure AD B2C - OIDC endpoint and SAML IdP initiated SSO endpoint.

• RealMe Insights: for persisting RealMe Context Mapping Service user auditing.

4.2.4. RealMe Extension Functions App

The following RealMe extension functions are created to support login and assertion user

journeys:

• Agency Config Retrieval

This function reads agency configuration details from agency config store and shares them

to Azure AD B2C in RealMe login and RealMe assertion user journeys.

• TOTP Reg & Validation

This function registers user’s TOTP key in RealMe user directory through Azure AD Graph

API. This function also confirms the user provided OTP generated through Authenticator

app to Azure AD B2C in RealMe login multifactor authentication journey.

• Get Identity Attributes



This function invokes RealMe consent service, identity verification service and address

verification service to get the user’s identity and address attributes to support assertion

service journey.

• Get Contact Details

This function retrieves user’s email address, mobile phone from Azure AD B2C Graph API to

share them with the requesting agency.

• SAML Artifact Resolve Service

This function reads SAML Artifact response from Artifact response store shares it with the

requesting relying party.

• FLT Generation and Retrieval

This function generates user’s FLT, persists against the relying party privacy domain in Azure AD B2C user directory as an extension attribute through Azure AD Graph API and shares it with Azure AD B2C on the user successful authentication.

4.2.5. RealMe Insights

RealMe Insights is combination of an Azure Application Insights and Azure Log Analytics

components. All RealMe architecture components integrate with the RealMe insights to provide

system level, application level and user activity logging.

Note: Refer to https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview

for more details regarding Azur Application Insights.

4.2.6. RealMe System Monitor

The RealMe System Monitor component monitors and alerts RealMe application and

infrastructure resources by inspecting RealMe Application Insights logging. It provides full stack

visibility, finds and fixes problems, allows to optimise performance, and understand the user

behaviours all in one place.

Note: Refer to https://docs.microsoft.com/en-us/azure/azure-monitor/overview for more details

regarding Azure Monitor.

4.2.7. RealMe Key Vault

RealMe Key Vault component is an Azure Key Vault component. The RealMe Key Vault persists

RealMe Azure resources keys and certificates. The relying party service client keys are also saved

in RealMe Key Vault.

4.2.8. RealMe Health and Performance Check

RealMe Health and Performance Check is an Azure web application component. The web

application is a .Net web service and utilises selenium libraries to automate health check at regular

periodic intervals to test the availability and user experience of RealMe services. The same

application also performs testing in ITE environment using selenium libraries.

https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overviewhttps://docs.microsoft.com/en-us/azure/azure-monitor/overview



4.2.9. RealMe Helpdesk

The following are the key business objectives for the RealMe helpdesk solution:

• to provide better experience for the service desk operators and

• standards based integration approach to reduce development cost for agencies

Figure 9: RealMe Helpdesk Access

Below are the key points regarding message flow:

• The agency service desk operator is authenticated using agency enterprise credentials. The

service desk operator receives a call from the user for the RealMe support.

• The service desk operator validates the user and may identify the user if they are existing

agency customer. The service desk operator triggers the RealMe support process from the

Agency service desk application.

• The agency service desk application redirects the operator to the agency IAM product to

initiate seamless single sign-on process with the RealMe helpdesk web application.

• The agency IAM product creates SAMLv2.0 assertion with operator identifier as name id

and the user’s FLT an attribute if the service desk operator identifies the user.

SAMLv2.0 SPAzure AD B2C


Agency IdP Metadata

Configuration

HD OperatorsCredentials Store

Agency Service Desk

MBIEDIA IR MSD

2. SAML IdP Initiated SSO


3. redirect with operator token

RealMe Helpdesk

Webapp

RealMe Front Door

Recover username Reset password Search user User summary

Transaction details

Update contact details

RealMe Helpdesk Business Functions

implements

Update 2FA Methods

Azure AD B2C

Graph API

RealMe

Get User Details

Agency Service Desk Operator

1. Access RealMe HD Web app

4. HD Landing Page



• The agency IAM product signs and encrypts SAMLv2.0 assertion and creates a SAMLv2.0

response with the SAMLv2.0 assertion.

• The agency IAM product redirects the service operator to the RealMe Helpdesk Federation

Hub with SAMLv2.0 response using IdP initiated SSO.

• The RealMe Helpdesk Federation Hub decrypts the SAMLv2.0 assertion and verifies the

signature of the SAMLv2.0 assertion.

• The RealMe Helpdesk Federation Hub identifies the operator based on operator identifier.

If there is no service operator found, then creates service operator account with the

operator email address and agency identifier (i.e. SAML entity id).

• The RealMe Helpdesk Federation Hub creates operator token (JWT) and redirects the

service desk operator to the RealMe Helpdesk web application.

Below are the key Integration dependencies for RealMe Helpdesk web application:

• Azure AD Graph API: for retrieving user details and updating user details.

• Agency Config Retrieval Function: for retrieving the relaying party helpdesk service configuration.

• RealMe Insights: for persisting RealMe Helpdesk operator transactional auditing.

Note: The helpdesk operator details are stored in RealMe Helpdesk Federation Hub.



5. Solution standards

5.1. Standards

Standard or good practice Description

Application Design https://www.digital.govt.nz/standards-and-guidance/design-

and-ux/service-design/service-design-overview/

Application UI standards https://www.digital.govt.nz/standards-and-guidance/design-

and-ux/accessibility/

Software Development

Framework

.NET

ICT API standards (AoG) https://www.digital.govt.nz/standards-and-

guidance/technology-and-architecture/application-

programming-interfaces-apis/

Te Tari Taiwhenua ICT Strategy DIA cloud adoption strategy

Te Tari Taiwhenua AD EA

Guideline

State the location

Messaging Standards

SAML v2.0, OAuth2.0, Open ID Connect, JSON Web Token

(JWT), CIQ XML for sharing identity and address details

Message Security Standards

[Examples – WS-Security Policy

v1.2, WS-Security v1.0, XML

Digital Signatures]

SAMLv2.0 XML Digital Signature, JSON Signature and Web

Encryption ( JOSE)

https://dia.cohesion.net.nz/Sites/IT/_layouts/15/WopiFrame.aspx?sourcedoc=%7b485BA0D6-4017-4EB9-81D7-62A160E381C2%7d



6. Technology Architecture view

The RealMe login and RealMe assertion services are deployed in Microsoft Azure Cloud Platform.

The RealMe services are configured/deployed in Azure AD B2C and other RealMe Azure PaaS

resources are also deployed to support RealMe services.

6.1. Network architecture

The network management between Azure components are managed by Microsoft Azure Cloud

Platform and it is a black box for the RealMe solution.

6.2. Infrastructure architecture

The infrastructure supporting Azure AD B2C and the RealMe Azure PaaS capabilities is a black box

for the RealMe solution, and it is the responsibility of Microsoft Azure Cloud Platform to manage

underneath infrastructure.

6.3. Hosting and sites

The RealMe Azure solution involves two key architecture components groups:

Architecture Components Datacenter Comments

Azure AD B2C Primary Datacenter:

Australia East

Secondary

Datacenter: Australia

South East

Azure AD B2C is an Identity Experience

Framework engine built on top of Azure

AD.

RealMe user credential data is saved in

Azure AD. Azure AD is a high availability,

geo-redundant failover capability. The

user data is always read from primary

datacenter. In the event of failure with

primary datacenter, Azure AD B2C

service reads the data from secondary

datacenter.

There is no Guarantee that AU

datacenter will be used for the Azure AD

B2C Service (Separate to Data at rest) if

there are issues or the service becomes

congested traffic will route to other

locations.



RealMe Azure Resources Primary Datacenter:

Australia East

Secondary

Datacenter: Australia

South East

The traffic is always routed to primary

datacenter. Azure Front Door

automatically routes the traffic to

secondary datacenter in case of failure in

primary datacenter. The expected delay

in auto failover to secondary datacenter

is less than 2 minutes.

Table 4: Hosting



7. Security view

All aspects of the Azure AD B2C service from development through to operation, adhere to the

Microsoft Cloud and AI divisional requirements. This includes following the Security Development

Lifecycle (https://www.microsoft.com/en-us/securityengineering/sdl/), privacy by design, and the

fully managed and controlled DevOps environment. The comprehensive security approach for

Microsoft Azure Platform and Services is available at https://www.microsoft.com/en-

us/trustcenter/compliance/complianceofferings?product=Azure, including the NZCC framework

(https://www.microsoft.com/en-us/trustcenter/compliance/nzcc).

The following table describes the Security View which explains how the Security Requirements are

met for the RealMe Re-platforming Solution:

Security Service Application/Service Layer Azure Platform Layer/ Governance Layer

Access Control

Unauthenticated users cannot access RealMe

application services.

User Segment:

The users must authenticate using their low

strength or multifactor authentication to

access RealMe services. The users can also use

multifactor authentication to manage their

logins.

Staff Segment:

RBAC (Role Based Access Control) is enforced

on the RealMe Helpdesk Web application.

Below roles are defined for the helpdesk web

application access:

• RealMe Administrator

• RealMe Operator

• Agency Administrator

• Agency Operator

The above roles are managed in the RealMe

Helpdesk Federation Hub.

Systems:

Certificate based authentication or Client keys

is enforced to control the access between the

architecture components involved in the

solution.

The following Azure Platform Roles are assigned to the RealMe resource group in the DIA Azure AD tenancy:

1. Role: Administrator, Security Group: RealMe Platform Administrator. Users: DIA CDOT Team and UNIFY RealMe Administrator Team

2. Role: Contributor, Security Group: RealMe Platform Contributor. Users: UNIFY Managed Service Team and the Service Accounts created in the DIA Azure AD to support Azure DevOps Pipeline and release process.

https://www.microsoft.com/en-us/securityengineering/sdl/https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings?product=Azurehttps://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings?product=Azurehttps://www.microsoft.com/en-us/trustcenter/compliance/nzcc




Authentication

Service

RealMe login service is an authentication

service for users. The login-initiated flows are

configured in Azure AD B2C as authentication

service.

DIA and Agency support staff access RealMe

Helpdesk web application using their

credentials through RealMe helpdesk

federation hub.

System level authentication is through

certificate authentication and or client keys.

Authentication to Azure portal to access

RealMe resources under DIA Azure Tenancy is

through DIA credential authentication.

Authorisation

Service

There are minor authorisation policies enabled

for users in the context of manage login.

Role based authorisation is enabled in RealMe

helpdesk web app. The agency administrator

and agency operator are authorised to access

transactional data specific to agency privacy

domain.

The DIA Administrator role has more privileges

than DIA operator. DIA operators can access

transaction data related all agencies.

Only authorised RealMe resources, i.e. RCMS,

Helpdesk Portal and Function Apps can access

Graph API access. These resources are

registered in Azure AD B2C.

The following roles are mapped to authorise the

access to the RealMe Azure AD B2C and other

resources:

1. Role: Global Administrator for Azure AD B2C

Security Group: RealMe Platform Administrator.

Users: DIA CDOT Team and UNIFY RealMe Administrator Team will be part of this Security Group

2. Role: B2C IEF Keyset Administrator

(Role having Permission to manage

certificates and Client Secrets from

Azure DevOps Release Pipeline)

Users: A Service Account created in the

DIA Azure AD and assigned to this role.

3. Role: B2C IEF Policy Administrator (Role

having Permission to manage IEF

Policies from Azure DevOps Release

Pipeline)

Users: A Service Account created in the

DIA Azure AD and assigned to this role.

4. Role: Contributors.

Security Group/Users: UNIFY Managed

Service Team and the Service Accounts

created in the DIA Azure AD to use in

the Azure DevOps Pipeline.




Certificate

Services

RealMe login and RealMe assertion service

signing keys are stored in RealMe Azure AD

B2C keystore and RealMe Azure Key Vault.

The client keys and other RealMe resource keys

are saved in RealMe Azure key Vault.

TLS Certificates for Azure AD B2C, RealMe

Extension Functions App and RCMS, RealMe

Helpdesk web application are managed though

DIA Azure portal.

Directory

Services

RealMe user credential data is stored in

RealMe Azure AD B2C user directory.

RealMe helpdesk operator data is stored in the

RealMe Federation Hub Azure AD B2C user

directory.

Azure AD is used as a directory service for the

Azure platform.

Federation

Services

RealMe instance of Azure AD B2C acts as

federation service for the agencies.

Another instance of Azure AD B2C acts as a

federation hub for the helpdesk operators.

There is no external federation required at

Azure AD.

Audit and

Event Logging

RealMe Azure AD B2C component and other

RealMe components log the audit and system

transactions into the RealMe App insights

which is monitored and reported using RealMe

System Monitor. The RealMe App Insights

contain:

• User Transaction activity

• System Logging

• Agency Transaction activity

• Helpdesk Transaction Activity

There is built-in logging at Azure RealMe

resources level, but the retention period for

these logs are only limited period (i.e.7 days).

Azure Monitor will be configured to archive

these logs.

Intrusion

Detection and

Prevention

Azure Front Door allows to custom Web

Application Firewall (WAF) rules for access

control to protect backend RealMe Azure

Services. Front Door platform itself is

protected by Basic Azure DDoS Protection.

Azure Active Directory B2C (Azure AD B2C) has

built-in features that can help to protect against

threats to resources and data. These threats

include denial-of-service attacks and password

attacks. The network security is also managed

by Azure AD B2C.

https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview




SIEM RealMe Azure System Monitor and RealMe

health checker application perform the

analysis, health check, monitoring and alerting

functions. UNIFY Manage Team provide manual

intervention capability to fix any issues.

But the application services can also integrate

with any enterprise SIEM capabilities such as

Azure Sentinel or Splunk etc in future.

Azure Platform is designed to withstand attacks

generated from both outside and inside the

platform. The Basic DDoS protection is

automatically enabled as part of the Azure

platform. Azure DDoS Protection Basic tier

provides always-on traffic monitoring with near

real-time detection of a DDoS attack, with no

intervention required. DDoS Protection

automatically mitigates the attack as soon as

it’s detected. The DDoS service understands

your resources and resource configuration and

uses intelligent traffic profiling to learn

application traffic patterns over time.

The platform can also integrate with any

enterprise SIEM capabilities such as Azure

Sentinel or Splunk etc in future.

Trusted Time The audit logs from RealMe Azure AD B2C

Journey, RealMe Azure resources contain the

creation and modification dates of the user

records.

Azure AD B2C has built-In audit events store

which captures the creation and modification

time stamps of the user records.

Non-

Repudiation

RealMe Azure Services auditing provide the

evidence that link users and relying parties to

the transactions. The audit logs are saved in

RealMe App Insights.

Azure Platform auditing provides the evidence

that link users and relying parties to the

transactions. Platform audit logs are saved in

RealMe App Insights.

Data

Anonymization

and Redaction

Data is anonymised through encryption at rest

and in transit such as Encrypted JWT. The audit

logs won’t have any personalised information.

Data is anonymised through encryption at rest.

The audit logs won’t have any personalised

information. Azure AD B2C uses BitLocker to

encrypt the data. All Azure services use the

service-managed Keys to encrypt the data at

server side.

Database

Access Control

There is no direct access to RealMe user

credential data. The credential data is only

accessed through by RealMe Azure AD B2C and

RealMe Azure Services. These applications

access is given through Azure portal.

The storage account resources have no

personalised information, are restricted for

access to the authorised users only. The users

of the administrator and contributor roles have

permission to access the storage account

resources.

Database

Encryption

There is encryption at storage account

resources even though they don’t have any

personalised information.

The RealMe credential data is encrypted at rest

in Azure AD.




Database

Integrity

Agency configuration table stores the

configuration for the agency RealMe

integration. Any changes to the data are

validated through automated integration test

script. The App insights user activity logs will

contain object id of RealMe credential store in

Azure AD.

RealMe user credential data is stored in RealMe

instance of Azure AD B2C and Helpdesk

operators credential data is stored in Helpdesk

federation instance of Azure AD B2C. The Azure

AD B2C takes care of data integrity.

File Integrity The RealMe storage account contains user

interface files and the service provider

metadata files and they are validated using

automated test scripts. Only the RealMe

platform administrator users and RealMe

platform contributor users have access to

these Files.

Azure AD B2C IEF configuration files integrity is

validated through automated test scripts. Only

the RealMe platform administrator users and

RealMe platform contributor users have access

to these Files.

Message

Integrity

The SAML request and SAML assertion

messages are signed in login, assertion service,

helpdesk federation flows involving relying

parties. RealMe Context Mapping service

issues JWT which is signed using RealMe login

signing key.

All the front channel communication messages

are signed or encrypted using the PKI

certificates to make sure that the message

integrity is maintained.

Network

Encryption

The application components communication is

over TLS1.2.

The application components communication is

over TLS1.2.

Software

Integrity

Azure DevOps platform is leveraged to

maintain the source code and configuration of

the solution. The developed components are

unit tested by the developers before

committing the changes to the repository. Peer

review process is in place for the source code

commit in the repository and upon committing,

an automated build and deployment is done on

the development environment. As part of the

automated build and deployment, the release

pipeline runs the automated test to validate

the source code from a deployment and

integration perspective.

realme login and realme assertion service · 2020. 2. 18. · realme login and assertion service...

Documents