Introduction and Brainstorming

OpenNCP versions before 2.4.0 implemented the epSOS specifications and their respective relaxations to give the possibility to member states to pilot. After the end of epSOS all the security relaxations ended, thus the OpenNCP architecture is revisited. One of the missing component in the OpenNCP architecture is the Workflow Manager, defined in  section 3.2.3 of 1. WorkflowManager and National Connection (Section 3.2.11) are necessary to allow national infrastructures (e.g., fat clients) or portals (through portal adapters, as in Figure 1 of 1). By definition, the Workflow Manager component realizes a Process Manager pattern, and it is the entry point in the business layer of the NCP. Citing Section 3.2.3, 

The WorkflowManager is called from the InboundProtocolTerminator as well as from the NationalConnector. This component realizes a Process Manager pattern. It is the entry point into the business layer of the NCP. Therefore this component is the first to be called after a message is received and deserialized. The WorkflowManager acts as orchestrator and realize the chain of operations call. The operations are exposed by interfaces of others components of business layer and, at the end, the result will be passed to the OutboundProtocolTerminator or to the National Connector. 

The Process Manager pattern is defined in 2 as follows:

How do we route a message through multiple processing steps when the required steps may not be known at design-time and may not be sequential?

Use a central processing unit, a Process Manager, to maintain the state of the sequence and determine the next processing step based on intermediate results.

The process manager has been introduced to keep the NCP stateless. It was named persistence layer in the FET implementation (D3.9 Annex2). 

The main idea is that the state of the sequence starts with the creation of the IdA, where a request comes from the NI (or from the portal adapter) containing credentials, and such credentials are used to obtain the new Assertion from the STS (to be developed in OpenNCP). 

This IdA is the token brokering the trust and identifies the session. All the subsequent transaction MAY re-use the same IdA, until a logout happens. (Picture from 3.8).

The WM and the NC implement the Process Manager. The WM knows the sequence while the NC knows how to interact with the national infrastructures. This is the reason of the decoupling.
The WM is one, while NC may come from the OpenNCP, from a vendor, or from the member state. 

The ideal workflow is therefore as follows:

FAT Client -> (National Connector -> Workflow manager) -> Local Outbount PT -> Remote inbound PT -> (Workflow Manager -> National Connector) -> FAT Client

( ) is the Process Manager

An example of the implementation of the initUser() method of the national connector can be: 

public SessionID initUser(Username, Role, Speciality) {
   credential = getCredentialFromChannel();
   trust(credential);
   Assertion ida = initUser(Username, Role, Speciality);
   sessionID = createSessionID;
  addToCache(sessionID, ida) ;
  return sessionID;
}

And an example implementation of the initUser() of the Workflow Manager can be:

public Assertion initUser(username, role, speciality) {
   getUsercredentials();
   WSTrustRST rst = new WSTrustRST(user, role, speciality, spubject, ...)
    rst.getAssertion();
    return assertion;
  
}

so that the workflow manager keeps the NCP gateway stateless. The session state is held in the NC. 

The workflow manager may expose APIs like

• public Assertion initUser(Username, NationalRole , Speciality);
• public XCPDResponse doXCPD(Assertion IdA, XCPDRequest)
• public XCARequest(Assertion IDA, Assertion TRC, XCARequest)

so that by polymorphism we can have the sequence implemented, as required by the process manager. 

National connector is called by NCP-B and NCP-A, as defined in 3.8-3.9 JWG epSOS deliverable, and in the http://www.epsos.eu/technical-background/reference-implementation/the-national-interface-connector.html.

Questions

Which API can the national connector expose? An implementation should be made available by the OpenNCP. An implementation that uses plain IHE ITI transactions has been suggested. Discussion in the TF whether these transactions can be SOAP or REST (FHIR?). Relevant profiles for FHIR will be IUA, MHD, RESTFul PIX,  PDQm, RESTFul ATNA. 

Do we need REM evidences?

What is the portal adapter? To be asked to Marcello Melgara. 

Access Control component

Another missing component for the workflow manager is the access control: 

TO BE DONE: national roles will arrive to the STS, which will consult a file, named role-mapping (for which we have an xsd) that legally binds each national role to an epsos equivalent, with a list of PERMISSIONS, using a mapping file.

Sample role mapping file. 

<?xml version="1.0" encoding="UTF-8"?>
<epsos:role-mapping 
    xmlns:epsos="urn:epsos:access-control:role-mapping"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:epsos:access-control:role-mapping        
file:/Users/max/Desktop/role-mapping.xsd">
    <epsos:role role-name="Arzt">
        <epsos:epsosRole role-name="physician"/>
        <epsos:permission id="PRD-003"/>
        <epsos:permission id="PRD-004"/>
    </epsos:role>
    <epsos:role role-name="Stationsschwester" on-behalf-of="Arzt">
        <epsos:epsosRole role-name="nurse"/>
        <epsos:permission id="PRD-003"/>
    </epsos:role>
</epsos:role-mapping>

References

1 JWG_NCP_Architecture_HLDD_v1.0.pdf

2 Hohpe, Wolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison Wesley