Skip to content

Understanding a Single IA Node

This document explains what a single Integration Architecture (IA) node is, what problems it solves, and how its main components work together. It is intended to help readers:

  • Build a correct mental model of an IA node
  • Understand why identity, attributes, and access control come before data
  • Understand what changes when security is enabled
  • Read the How-to and Reference documentation with confidence

It is intended to be used alongside:

What is an IA node?

An Integration Architecture (IA) node is a secure data node designed to support trusted data sharing. At a high level, an IA node:

  • Stores linked data
  • Authenticates users and systems
  • Enforces access control policies
  • Exposes data through standard APIs
  • Optionally ingests data from event streams

In the National Digital Twin Programme, IA nodes form the boundary between:

  • Data providers
  • Data consumers
  • Governance and policy controls

They allow data to be shared without copying or centralising it, while still enforcing who can see what.

What does “single IA node” mean?

A single IA node is the smallest useful deployment of the IA architecture. It includes:

  • One identity provider
  • One access service
  • One secure graph runtime
  • One set of access control policies
  • One set of APIs

Although it is often described as a “single node”, it is composed of multiple services working together. Single IA nodes are commonly used for:

  • Local development
  • Learning and experimentation
  • Reference implementations
  • Policy validation
  • Integration testing

How node levels relate (N0.1 and N1)

A local single IA node corresponds to a pre-production reference deployment below N1 level. It is sometimes referred to as an N0.1 node, meaning:

  • The full IA architecture is present
  • The node runs as a single logical unit
  • It is not hardened, scaled, or operationally managed for production use

Higher node levels (such as N1) differ primarily in:

  • Deployment topology
  • Resilience and availability
  • Operational controls

The core architectural behaviour remains the same.

Core capability layers of an IA node

A single IA node can be understood as a set of layered capabilities.
Each layer builds on the previous one.

Identity

Identity establishes who is making a request. In an IA node, identity is:

  • Represented by a signed token (JWT)
  • Issued by an identity provider
  • Verified on every request

The token provides a cryptographically verifiable statement of identity that the node can trust. Nothing else in the IA node works correctly without identity.

Attributes

Attributes describe facts about an authenticated identity.

Examples include:

  • Group membership
  • Organisation
  • Clearance or role indicators

Attributes are not hard-coded into the graph and are resolved dynamically by an access service when a request is made. These attributes are later used to make access control decisions.

Access control (ABAC)

IA nodes use attribute-based access control (ABAC).

With ABAC:

  • Access decisions are based on attributes and context
  • Policies are evaluated dynamically
  • Permissions are not fixed to static roles

This allows policies such as:

  • Only certain organisations can see personal data
  • Different users see different views of the same dataset
  • Access can vary by purpose or context

Importantly, ABAC filters query results, rather than duplicating or partitioning datasets.

Data layer (Secure Agent Graph)

The data layer of an IA node is a secure RDF graph.

It is responsible for:

  • Storing linked data
  • Supporting named graphs and provenance
  • Enforcing access control during query execution

Security is applied inside the query engine itself, ensuring that users only see data they are permitted to see.

Interfaces and integration

IA nodes expose data through multiple interfaces:

  • SPARQL, for graph-native queries
  • GraphQL, for application-friendly access
  • Kafka (optional), for event-driven ingestion

All interfaces enforce the same security model.
The choice of API does not affect access control behaviour.

Why RDF is used

RDF represents data as relationships rather than rows and columns.

This makes it well suited to:

  • Combining data from multiple organisations
  • Evolving data models over time
  • Preserving meaning across systems
  • Supporting long-lived infrastructure

RDF allows IA nodes to integrate heterogeneous data without forcing a single schema upfront.

Why identity comes before data

In the IA architecture, identity and access control are established before data is exposed.

This ordering ensures that:

  • Every request is attributable
  • Access decisions are consistent
  • Policies can be enforced uniformly

The How-to reflects this by validating identity and attributes before starting the secure graph.

Minimal versus secure node behaviour

A single IA node can run in different modes:

  • Minimal mode: data storage and querying only
  • Secure mode: authentication and ABAC enforced
  • Secure with integration: secure mode plus Kafka ingestion

These modes exist to support development and validation.
They allow individual layers to be tested in isolation before being combined.

Local and cloud deployments

The How-to focuses on running a single IA node locally using emulated services.

In cloud environments:

  • Local emulators are replaced with managed services
  • Persistent storage is used
  • Networking and security are externally managed

The IA node architecture itself does not change.

Summary

A single IA node is:

  • A secure, policy-enforcing data node
  • Built around identity, attributes, and linked data
  • Designed to support trustworthy data sharing

Understanding these concepts makes it much easier to run, configure, and reason about IA nodes as they scale.