Welcome

This architecture section describes the overall design of the Platform, its main building blocks, and how they interact. It is intended for readers who want to understand the technical details of the Platform, including core developers, tool developers, and IT admins considering the security of the Platform.

Overview

The documentation is split into multiple aspects, we recommend you first look at the detailed graphical overview of FL-Net to get a understanding of the architecture and its components. This is different than the simple graphical overview you may have read already.

Afterwards, we recommend to read the Network architecture section:

Network architecture

The network architecture describes the overall design, including network topology and exact connection patterns between the Platform and Clients.

After reading this please jump in to the more detailed sections either describing the Client (also called Site) or the Platform, depending on your interest:

Client

• The technical architecture of the client describes the internal structure of the client, including its components, how they interact and how they are deployed.
• The data flow of the Client goes into detail about which data flows in and out of a Client.

Platform

• The technical architecture of the Platform describes the internal structure of the Platform, including its components, how they interact and how they are deployed.

Security

While the security is also explained via the network architecture and technical details, a dedicated page describes the security model of FL-Net.

Disclaimer (IN DEVELOPMENT)

This documents the production ready version of FL-Net. However, the software is currently in development, so some of the claims may change:

• The permission system for statistics is not yet implemented and therefore might change a bit in the future

Furthermore, some systems are not yet implemented:

• Any Tool requiring internet access is not specially handled right now and can still be run via automatic approvals
• mTLS is not yet implemented between Controller and Relay Server. An application level auth of controllers to the Client exists
• The deployment always adds both the Learning API and Controller, even when the tool only requires the Learning API.
• The controller/relay server do not yet protect their endpoints for fl orchestration from tools to access them. However, tools can not meaningfully impact the system via these endpoints, as only create and delete methods are available.
• The data admin vs data access manager access is not yet fully checked and implemented.
• The learning apis/orch api have not yet been completely checked to ensure all endpoints are secured with the correct roles and permissions. Orch APi does not use auth at all yet.
• The datamodeler does not use auth at all yet
• The platform cannot run an aggregator currently, the aggregator is instead run only on the participating clients currently
• Currently, the frontend deployment requires two separate Nginx instances. These will eventually be consolidated into a single Nginx instance.
• Currently the API keys for communciation between Tools and the Controller are generated on the Platform and distributed, NOT generated by the local learning api
• The controller/relay server don't yet SHA-256 hash the API keys, this will be fixed in the future