Configuring application connections by software topology

This page explains how you can deploy software in different topologies for your end users while avoiding some of the security risks this can create.

Unless it's for your own use, as a software development organisation, you typically develop software products for use by your end user 'commissioners', or 'customers', also known as end user organisations (EUOs).

We sometimes refer to your role in this as being the 'connecting party' who takes technical (and legal) responsibility for connecting your EUOs to our APIs. You normally get approval to do this from us as part of the onboarding process, before your applications can go live.

Note that we also use the same roles and terminology, 'connecting party' and 'EUO' in our legal agreements with you, specifically our connection agreements and end user organisation acceptable use policy.

There are several different topologies you can use to deploy your software products to your EUOs. As you typically have multiple EUOs connecting via your production applications to our APIs, you need to prevent one EUO:

• accessing data from another EUO
• updating data that does not belong to it

The basic way to secure a connection is to create a separate production application for it. This applies to production applications in much the same way as it does to creating separate applications for separate testing environments, like deployment or integration, to avoid any risk of cross-contamination of test data.

Consider creating separate production applications when you:

• have several distinct products in production
• deploy your product in multiple places, such as on premises and in the cloud
• deploy your product in multiple regions
• deploy your products for each customer, such as once per trust (sometimes called a tenanted solution)

The advantages of this approach are that:

• each product has its own credentials, so if one of these is compromised then the impact is much reduced
• data contamination between products is much less likely to occur through misconfiguration 
• it aligns with cyber security requirements in many organisations, and builds on the 'defence in depth' strategy
• it allows clearer management of activity and risks to both you and us, at NHS Digital

There are 5 basic connection topologies as follows:

Notes:

• these topologies apply to both application-restricted access (no user present) and user-restricted access modes
• the EUO itself might be an actual application on a server, or just a web client

Here, an EUO connects directly via you as the connecting party.

They connect to an Apigee production application that you created which accesses our API and the back-end system.

Here, multiple EUOs connect to your cloud solution with you as the connecting party.

They connect to an Apigee production application that you created which accesses our API and the back-end system.

Their interactions with the API are shared as they travel over your cloud connections.

Here, multiple EUOs connect to your 'tenanted' cloud solution with you as the connecting party.

They connect to dedicated (tenant) Apigee production applications that you created which access our API and the back-end system.

Their interactions with the API are kept separate as they travel over your cloud connections.

Here, multiple EUOs connect to your 'grouped' tenanted cloud solution with you as the connecting party.

Some unrelated EUOs connect to dedicated Apigee production applications that you created which access our API and the back-end system.

Some related EUOs connect to a shared Apigee production application that you created which accesses our API and the back-end system.

Here, multiple EUOs connect directly via you as the connecting party.

They each connect to a separate Apigee production application that you created which accesses our API and the back-end system.