realme login and realme assertion service · 2020. 2. 18. · realme login and assertion service...
TRANSCRIPT
-
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 3 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 4 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 5 of 58
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,
Service Delivery and Operations, DIA
David Philp
General Manager Partners and
Products,
Service Delivery and Operations, DIA
Russell Burnard
General Manager Business Operations,
Service Delivery and Operations, DIA
Samrat Choudhury
General Manager,
UNIFY Solutions
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 6 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 7 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 8 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 9 of 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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 10 of 58
• 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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 11 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 12 of 58
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
Any investment in RealMe
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
Any investment in RealMe
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 13 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 14 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 15 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 18 of 58
Architecture
Component
Technology Integration & Dependencies Comments
RealMe Assertion
Service
Azure AD B2C Integration with Azure Front Door
for below RealMe Azure
resources:
• RealMe Extension Functions App
• 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 Extension Functions App
• 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
RealMe Extension Functions App
The DIA service desk and
agency service desk staff uses
RealMe helpdesk web app to
support the customer.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 19 of 58
Architecture
Component
Technology Integration & Dependencies Comments
RealMe Extension
Functions App
Azure
Functions
App
RealMe Insights
Azure AD B2C Graph API
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 Extension Functions App
RealMe Insights
Azure AD B2C Graph API
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 20 of 58
Architecture
Component
Technology Integration & Dependencies Comments
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 22 of 58
• 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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 23 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 24 of 58
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
Identity Experience Frame Work
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 Federation Hub
RealMe Helpdesk
Webapp
Agency IdP Metadata
Configuration
UI
Store
RealMe
Insights
RealMe Extension Functions
SAML Artifact Resolve Service
Access to:
RCMS and Attribute Provider Integration, UI, App Insights
Get Identity Attributes
RealMe Azure Resources
External Integration
Verified Identity APIs
Address Retrieval APIs
Identity Verification Service Address Verification Service
Consent APIs
RealMe Consent Service
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 25 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 26 of 58
• 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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 27 of 58
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 Storage Account
RealMe Front Door
RealMe Extension Functions
Agency Config Retrieval
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 28 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 29 of 58
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)
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 30 of 58
Login User Journeys
Login/ Create Login
Identity Experience Frame Work
Assertion User Journeys
Assert
Identity Experience Frame Work
Assert and Login
RealMe Assertion SAML IdP Endpoint
Resource Owner Password Credential
OAuth2.0 Token Endpoint(LAT Issuer)
Azure AD B2C
UI
Store
RealMe
Insights
RealMe Extension Functions
5. Get Opaque Tokens for Consent, IVS or AVS
Get Identity Attributes
RealMe Azure Resources
External Integration
Verified Identity APIs
Address Retrieval APIs
Identity Verification Service Address Verification Service
Consent APIs
RealMe Consent Service
Relying Party
2. SAML Request
Agency Config Retrieval
RealMe Context Mapping Service (RCMS)
Agency Config Table Store
SP Metadata
Store
RealMe Storage Account
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
Resource Owner Password Credential
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 31 of 58
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/
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 32 of 58
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
RealMe Context Mapping Service (RCMS)
Service
Privacy Domain 1
2. Request for security token 3. request forward
4. Get User details for FLT of service
RealMe Azure Resources
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 33 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 34 of 58
Azure AD B2C
Graph API
RealMe Front Door
RealMe Context Mapping Service (RCMS)
Service
Privacy Domain 12. Request for seamless
security token 3. request forward
4. Get User details for FLT
RealMe Azure Resources
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 35 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 36 of 58
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
RealMe Helpdesk Federation Hub
Agency IdP Metadata
Configuration
HD OperatorsCredentials Store
Agency Service Desk
MBIEDIA IR MSD
2. SAML IdP Initiated SSO
RealMe Azure Resources
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 37 of 58
• 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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 38 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 39 of 58
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 40 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 41 of 58
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 42 of 58
Security Service Application/Service Layer Azure Platform Layer/ Governance Layer
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 43 of 58
Security Service Application/Service Layer Azure Platform Layer/ Governance Layer
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
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 44 of 58
Security Service Application/Service Layer Azure Platform Layer/ Governance Layer
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.
-
Solution Architecture Description RealMe Login and RealMe Assertion Service
UNCLASSIFIED Page 45 of 58
Security Service Application/Service Layer Azure Platform Layer/ Governance Layer
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.