Overview

Description: This workflow describes how authentication and authorisation of systems making use of the HIE is done through the HIM. This workflow provides the security underpinning for many other workflows that rely on a secure connection and authorised message delivery.

Sponsor:  Ryan Crichton, with the IL (HIM) community

Status:  Completed

Last Modified:  12rd March 2015

Referenced Standards and APIs:

Actors

 

title Common message security workflow
participant MoH
participant PoS
participant IL Core
participant IL RBAC
participant IL Orchestrator
participant Some registry
opt System registration occurs only once
	MoH->MoH: [1] The PoS application is approved (via the appropriate\n policy) to be able to communicate with the HIE
	alt if the PoS application DOES NOT have a certificate
		MoH->IL Core: [2] The IL is used to register the application and\n a certificate and key are generated for them
		IL Core->MoH: [3] The certificate and key are downloaded from the IL
		MoH->PoS: [4] The certificate and key are supplied to the PoS admin
		PoS->PoS: [5] The certificate and key are installed into the PoS application
	else if the PoS application HAS an existing certificate
		MoH->IL Core: [6] The IL is used to register the application and\n upload their existing certificate
	end
end
PoS->IL Core: [7] A message is sent over a secure connection using TLS\n mutual authentication
IL Core->IL Core: [8] The client certificate is validated to authenticate the\n PoS application (handled at the transport layer)
IL Core->IL RBAC: [9] Checks if the PoS has the authority to send this message\n on to the required registry
alt If deep inspection of the message is required to determine authority (not done at present)
	IL Core->IL Orchestrator: [10] Message forwarded
	IL Orchestrator->IL Orchestrator: [11] Inspects message contents
	IL Orchestrator->IL RBAC: [12] Checks if the application has the\n required authority
	IL RBAC->IL Orchestrator: [13] Returns true if the application has\n the correct authority
alt If the application has the correct authority
	IL Orchestrator->Some registry: [14] Message forwarded
	Some registry->IL Orchestrator: [15] Response returned
end
	IL Orchestrator->IL Core: [16] Response returned
	IL Core->PoS: [17] Response returned
else If deep inspection of the message is NOT required to determine authority
	IL Core->Some registry: [18] Message forwarded
	Some registry->IL Core: [19] Response returned
	IL Core->PoS: [20] Response returned
end

Technical details

Below enter each interaction that makes up the described workflow above.

 

 

RefInteractionEndpointDataTransaction Specification
1The PoS application is approved (via the appropriate policy) to be able to communicate with the HIE policy 
2The IL is used to register the application and\n a certificate and key are generated for them details about the application 
3The certificate and key are downloaded from the IL in .pem format 
4The certificate and key are supplied to the PoS admin in .pem formatSneaker-net
5The certificate and key are installed into the PoS application   
6The IL is used to register the application and upload their existing certificate   
7A message is sent over a secure connection using TLS mutual authentication  ATNA Node Authentication
8The client certificate is validated to authenticate the PoS application   
9Checks if the PoS has the authority to send this message on to the required registry   
10Message forwarded   
11Inspects message contents   
12Checks if the application has the required authority   
13Returns true if the application has the correct authority   
14Message forwarded   
15Response returned   
16Response returned   
17Response returned   
18Message forwarded   
19Response returned   
20Response returned