TAK Federation Hub : architecture, mise en place et quand le préférer à la fédération directe

Le TAK Federation Hub est un broker optionnel publié avec TAK Server. Au lieu que chaque TAK Server se fédère directement avec tous les autres, chaque serveur ouvre une seule connexion de fédération vers le hub ; le hub authentifie les fédérés et transmet les données selon un graphe de politique défini par l'administrateur, avec des filtres de groupes par arête. Utilisez-le dès que vous connectez plus de trois serveurs ou plusieurs domaines administratifs.

Cette page traite de la décision d'architecture (hub ou fédération directe de serveur à serveur) et de ce qu'implique l'exploitation d'un hub : versions du protocole et ports par défaut, modèle de politique, PKI, déploiement, exploitation et dépannage. Pour configurer un seul lien direct entre deux serveurs, utilisez notre guide de configuration de la fédération TAK Server.

• Ce que c'est : un broker en étoile (hub-and-spoke) pour la fédération TAK Server (gestionnaire de politique, broker de messagerie, interface web d'administration).
• Ports par défaut : 9102/tcp fédération v2, 9101/tcp fédération v1, 9100/tcp interface d'administration.
• Dépendances : Java 17 et MongoDB ; distribué en RPM, DEB et bundle Docker.
• Maturité : le guide de configuration TAK Server (version 5.7, mars 2026) qualifie encore l'installateur du hub de « beta ».

Pourquoi un Federation Hub : le problème N² de la fédération directe

La fédération directe est un accord bilatéral implémenté dans le logiciel. Selon le guide de configuration TAK Server, deux administrateurs échangent des certificats de CA, que chaque serveur conserve dans un truststore de fédération distinct de celui des utilisateurs locaux, afin que le serveur du partenaire puisse se connecter mais pas les appareils ATAK du partenaire. L'un des deux serveurs crée la connexion sortante, et chaque côté choisit quels groupes peuvent sortir de son serveur et y entrer. Les clients ne demandent aucune reconfiguration.

Cela convient à deux ou trois serveurs. Un maillage complet (full mesh) de n serveurs exige n(n−1)/2 liens : 6 pour quatre serveurs, 45 pour dix. Chaque lien suppose un échange de CA, une ouverture de pare-feu côté écoute et des réglages de groupes aux deux extrémités, et chaque changement de politique se répète lien par lien.

Le Federation Hub remplace le maillage par une étoile. Chaque TAK Server se fédère une seule fois, avec le hub, qui gère connexions et confiance et relaie chaque message le long des arêtes d'un graphe de politique, filtré par groupe TAK. Trois choses changent :

• Confiance : chaque TAK Server importe un seul CA externe, celui du hub, au lieu d'un par partenaire. Le hub détient les CA des partenaires.
• Joignabilité : les spokes appellent généralement le hub en sortie, donc les serveurs avancés derrière un NAT ou des pare-feu unidirectionnels n'ont besoin d'aucune ouverture entrante. Seul le hub écoute.
• Politique : qui reçoit quoi vit dans un seul graphe au lieu de dizaines de réglages par serveur, tandis que chaque serveur continue de contrôler ce qui le quitte.

Les coûts sont réels aussi : un saut de broker supplémentaire sur chaque message inter-serveurs, un nouveau système à haute valeur qui termine chaque session de fédération et voit tout le trafic relayé, et un point de défaillance unique pour le partage entre serveurs. Quand le hub tombe, l'image locale de chaque serveur continue de fonctionner ; seul l'échange s'arrête.

Versions du protocole de fédération et ports par défaut

TAK Server parle deux protocoles de fédération. La fédération v1 est l'originale : un socket TLS de longue durée transportant des événements fédérés encodés en protobuf. La fédération v2 transporte des messages protobuf sur gRPC (HTTP/2) avec le même TLS mutuel, et c'est la version activée dans la configuration d'exemple de TAK Server, où v1 est livrée désactivée. Le protocole se choisit par connexion sortante, et l'avertissement du guide s'applique : choisissez la version de protocole qui correspond au port auquel vous vous connectez. Pour le versant client, voir protocole TAK : CoT XML contre protobuf.

Ce sont des valeurs par défaut ; confirmez-les dans vos propres fichiers. Configuration d'exemple de TAK Server :

<federation>
  <federation-server port="9000" v1enabled="false" v2port="9001" v2enabled="true">
    <tls context="TLSv1.2" keymanager="SunX509"
         keystore="JKS" keystoreFile="certs/files/takserver.jks" keystorePass="atakatak"
         truststore="JKS" truststoreFile="certs/files/fed-truststore.jks" truststorePass="atakatak"/>
  </federation-server>
</federation>

Et la configuration du broker du hub, /opt/tak/federation-hub/configs/federation-hub-broker.yml (extrait) :

v1Enabled: true
v1Port: 9101
v2Enabled: true
v2Port: 9102
dbPort: 27017

Règle pratique : normalisez toutes les connexions sur v2, pointez les connexions sortantes de TAK Server sur le 9102 du hub, et coupez v1 sur le hub sauf si un pair historique en dépend. Le filtrage par groupes en dépend aussi : les connexions v1 ne transportent aucune information de groupe TAK vers le hub, donc toute arête filtrant par groupe rejette le trafic v1.

Comment le Federation Hub route le trafic : graphe de politique et filtres de groupes

Le hub tourne comme des services Java coopérants sous un même service système federation-hub : un gestionnaire de politique, un broker de messagerie et une interface web d'administration (les paquets récents ajoutent un gestionnaire de plugins). Le routage vient d'un graphe de politique que vous dessinez dans l'interface. Ses nœuds sont :

• Groupes de CA : tout fédéré dont le certificat remonte par chaîne vers un CA téléversé rejoint le groupe de ce CA. La plupart des politiques s'écrivent contre des groupes de CA, donc en pratique contre des organisations.
• Fédérés : des TAK Server individuels, quand un serveur exige un traitement différent du reste de son organisation.
• Connexions sortantes : connexions que le hub lui-même ouvre vers un TAK Server ou un autre hub — c'est ainsi qu'on bâtit des topologies multi-sauts de hub à hub.
• Groupes à jeton : des fédérés qui s'authentifient par jeton plutôt que par TLS mutuel.

Les arêtes sont orientées. Une arête de A vers B laisse le trafic de A atteindre B, pas l'inverse, donc le partage bidirectionnel exige deux arêtes, et les flux à sens unique (un partenaire qui reçoit votre image des forces bleues mais ne renvoie rien) sont un motif pleinement pris en charge. Chaque arête porte un filtre de groupes : tous les groupes, groupes autorisés, groupes interdits, ou autorisés et interdits. Les groupes sont les groupes TAK Server attachés à chaque message, que les utilisateurs ATAK voient comme des canaux. Un message passe une arête à liste d'autorisation si au moins un de ses groupes y figure, et échoue sur une arête à liste de refus si l'un de ses groupes y figure ; un message sans groupes ne passe qu'une arête « tous les groupes ».

Les groupes de CA ont aussi un indicateur Interconnected : les membres d'un groupe interconnecté s'échangent tout, sans arête ni filtrage. C'est commode au sein d'une organisation et dangereux dans une coalition — vérifiez-le pour chaque groupe ajouté. L'éditeur sépare aussi l'enregistrement d'une politique de son activation ; une politique enregistrée mais inactive ne change rien.

Minimisation des données : trois étapes de filtrage

1. TAK Server source : les groupes sortants définis pour le fédéré du hub décident ce qui quitte votre serveur. Dans une coalition, c'est la seule étape que vous contrôlez entièrement.
2. Arêtes du hub : elles décident quelles destinations reçoivent quels groupes.
3. TAK Server de destination : les groupes entrants et le mappage des groupes fédérés décident quels utilisateurs locaux voient le trafic entrant.

Les fichiers ont leurs propres règles. Le bloqueur de Data Package et de Mission File de TAK Server bloque les fichiers fédérés par extension (pref par défaut, afin que des fichiers de configuration ne reconfigurent pas les appareils des partenaires), et la fédération des missions est une décision distincte du partage CoT ; voir paquets de données et paquets de mission TAK. Le guide énonce aussi franchement la limite : chaque domaine contrôle ce qu'il partage, pas ce que l'autre domaine en fait. Les clients restent hors de tout cela : ATAK, WinTAK et les clients navigateur comme CloudTAK continuent de parler à leur propre serveur.

Modèle de confiance des certificats : CA, identités des fédérés et révocation

La confiance de fédération repose sur un TLS mutuel adossé aux CA. Dans une topologie à hub :

• Chaque TAK Server importe le CA du hub dans son truststore de fédération (l'interface du hub peut télécharger son propre CA) et présente son certificat de serveur à la connexion.
• Le hub importe le CA de chaque organisation ; le téléversement crée le groupe de CA auquel la politique se réfère.
• L'identité d'un fédéré est son certificat, et sa chaîne d'émission détermine ses groupes de CA. Un serveur dont la chaîne comprend un CA intermédiaire peut atterrir dans plusieurs groupes de CA — il faut alors que les arêtes de tous autorisent le trafic.

Quatre règles de conception en découlent :

• Utilisez un CA de fédération dédié par organisation. Le guide de configuration décrit cette variante — un CA et un certificat de serveur séparés, utilisés uniquement pour la fédération — pour que les partenaires ne voient jamais le CA qui signe vos certificats clients, et retirer un CA du hub ne coupe qu'une seule organisation.
• Planifiez la révocation avant d'en avoir besoin. Les arêtes écrites contre un groupe de CA s'appliquent à chaque serveur de ce CA. Pour couper un serveur compromis sans toucher son organisation, donnez aux pairs à haut risque des arêtes par fédéré ou appuyez-vous sur la vérification de révocation (le broker du hub a une option OCSP, désactivée par défaut). Les réseaux isolés sans répondeur OCSP reposent sur des durées de vie courtes et un exercice répété de retrait de CA.
• Protégez la clé du hub comme une clé de CA et changez les mots de passe par défaut des keystores (atakatak dans les exemples livrés) : quiconque détient la clé du hub peut se faire passer pour lui auprès de chaque spoke.
• Traitez l'authentification par jeton comme une exception. TAK Server et le hub peuvent authentifier la fédération par jetons là où des proxys à inspection TLS (« break and inspect ») rendent le TLS mutuel impossible ; le guide lui-même note que les jetons sont moins sûrs que mTLS.

Pour la conception PKI entre nations partenaires, voir la gestion des identités en coalition.

Installation du Federation Hub et options de déploiement

Le hub est distribué sur tak.gov comme son propre paquet à côté de TAK Server : takserver-fed-hub en RPM (RHEL, Rocky) ou DEB (Ubuntu, Debian), plus un bundle Docker qui associe une image du hub à une image MongoDB distincte. Il exige Java 17 et MongoDB, où le broker stocke événements de fédération et métadonnées, et fonctionne avec ou sans TAK Server colocalisé. Donnez à un hub de théâtre ou de coalition un hôte dédié : c'est une ancre de confiance pour chaque partenaire, et il ne doit partager ni domaine de défaillance ni équipe d'administration avec un spoke.

1. PKI. Créez le CA du hub et le certificat serveur avec les mêmes scripts et procédure que TAK Server (annexe B du guide de configuration) ; keystore et truststore se trouvent sous /opt/tak/federation-hub/certs/files/.
2. Installation. Installez Java 17, le paquet du hub et MongoDB ; définissez les identifiants de la base dans federation-hub-broker.yml et exécutez le script de configuration de la base du hub.
3. Démarrage et autorisation. Démarrez le service, autorisez un certificat d'administrateur et connectez-vous avec lui à l'interface sur le port 9100 (commandes ci-dessous).
4. Échange de CA. Téléversez le CA de fédération de chaque partenaire dans l'interface du hub et envoyez à chaque partenaire le CA du hub.
5. Dessinez la politique. Ajoutez des groupes de CA (et des fédérés individuels si besoin), reliez-les par des arêtes orientées, réglez le filtre de groupes de chaque arête, décidez d'Interconnected pour chaque groupe, puis enregistrez et activez.
6. Connectez chaque TAK Server. Activez la fédération v2, téléversez le CA du hub sous Federate Certificate Authorities, créez une connexion sortante vers le hub sur 9102 en protocole v2, puis réglez les groupes sortants et entrants du fédéré du hub.
7. Testez dans les deux sens. Envoyez une piste d'essai connue dans un groupe qui doit passer et une dans un groupe qui doit être bloqué (nos exemples de messages CoT annotés font des bancs d'essai pratiques), puis vérifiez que la vue Active Connections du hub affiche la version de protocole et les identités de groupes attendues.

sudo systemctl restart federation-hub
sudo systemctl enable federation-hub

# authorize an administrator certificate (written to authorized_users.yml)
sudo su tak
java -jar /opt/tak/federation-hub/jars/federation-hub-manager.jar /path/to/admin.pem
exit

# then open https://hub.example.org:9100/ and log in with that certificate

Haute disponibilité et supervision du Federation Hub

La documentation publique du Federation Hub ne décrit pas de hub clusteré en actif-actif : planifiez donc un secours chaud rapide plutôt qu'une indisponibilité nulle :

• Sauvegardez l'état du hub : certificats et keystores, fichiers de politique, authorized_users.yml, le répertoire configs et la base MongoDB. Les notes de mise à niveau du hub demandent de sauvegarder d'abord le fichier de politique et les utilisateurs autorisés.
• Gardez un secours aux certificats et à la politique identiques, derrière un nom DNS ou une IP virtuelle déplaçable. Les TAK Server se reconnectent seuls, selon l'intervalle de reconnexion défini sur chaque connexion sortante.
• Rendez les spokes résilients : une panne du hub arrête le partage, pas les opérations locales, donc l'essentiel du travail de disponibilité revient à chaque serveur ; voir haute disponibilité et clustering de TAK Server.
• Dimensionnez à partir de mesures : aucun dimensionnement publié spécifique au hub. Partez de la base TAK Server du guide (4 cœurs, 8 Go de RAM, 40 Go de disque), puis surveillez le tas et les débits de messages en charge d'exercice ; les leviers côté serveur sont dans l'optimisation des performances de TAK Server.

Supervisez à trois niveaux. Dans l'interface du hub, le tableau de bord des métriques montre connexions totales, lectures et écritures par seconde, octets par seconde, CPU et tas, et la table Active Connections liste pour chaque fédéré l'adresse distante, la version de protocole et les identités de groupes. Sur les hôtes, collectez /opt/tak/federation-hub/logs et suivez l'état de fédération de chaque TAK Server. À l'extérieur, sondez 9102 et 9100, alertez sur l'expiration des certificats — chaque CA de fédéré et chaque certificat serveur —, suivez le décalage NTP et déclenchez une alarme quand le nombre de fédérés connectés passe sous le nombre attendu.

Schémas opérationnels : hubs de théâtre, de coalition, d'exercice et par domaine

Hub de théâtre

Les unités subordonnées exploitent leurs propres TAK Server et se fédèrent vers le haut, vers un hub à l'état-major supérieur. Les unités gardent leur image locale quand la liaison de transport (backhaul) tombe, le hub décide quel échelon voit quels groupes, et des spokes qui appellent en sortie conviennent aux serveurs avancés derrière NAT ou terminaux satellite.

Hub de coalition

Chaque nation garde son TAK Server, son CA et ses administrateurs ; un hub opéré par la nation pilote ou par une partie mutuellement de confiance porte l'image commune, les arêtes orientées et les listes d'autorisation codant les décisions de diffusion. Les groupes sortants nationaux restent la première ligne de contrôle. Lorsque la coalition emploie aussi les formats OTAN, une passerelle à la frontière nationale assure la traduction ; voir relier CoT et normes OTAN et mettre en œuvre un affilié FMN.

Hub d'exercice

Un hub avec son propre CA d'exercice, des certificats à durée courte et une politique propre au scénario laisse les participants aller et venir sans toucher aux serveurs des uns et des autres. Ensuite vous retirez un CA et mettez la politique au rebut ; pendant l'événement, la table des connexions du hub sert aussi de tableau de présence et de santé.

Un hub par domaine de classification

Un hub filtre par groupe ; ce n'est pas une garde. Il n'inspecte pas le contenu au regard des règles de diffusion et n'est pas accrédité pour déplacer des données entre niveaux de classification. Exploitez un hub distinct par domaine de sécurité et ne reliez les domaines qu'au travers d'une solution inter-domaines accréditée, un produit à part avec sa propre accréditation ; voir architecture de solution inter-domaines.

Les hubs peuvent aussi ouvrir des connexions sortantes vers d'autres hubs, donc un hub national peut s'apparier à un hub de coalition. Gardez ces chaînes courtes : chaque saut ajoute de la latence et une politique de plus à maintenir cohérente.

Dépannage des connexions du Federation Hub

• L'établissement TLS échoue ou le lien se reconnecte sans cesse. D'ordinaire la chaîne : le spoke doit faire confiance au CA du hub (pas seulement à son certificat serveur), le hub doit détenir le CA émetteur du spoke intermédiaires compris, personne n'a pu substituer un certificat client, et rien n'a expiré.
• Connecté, mais rien ne circule. La politique, pas le réseau : le groupe de CA du spoke est-il dans la politique active, une arête existe-t-elle dans le sens attendu, le serveur source a-t-il défini les groupes sortants du fédéré du hub, la destination a-t-elle défini ses groupes entrants ?
• Certains groupes passent, d'autres non. Les noms de groupes doivent correspondre exactement, un message sans groupes ne passe que les arêtes « tous les groupes », et les connexions v1 ne portent pas de groupes. Sur le TAK Server récepteur, le mappage des groupes fédérés retombe sur les réglages de groupes du fédéré quand aucun mappage ne correspond.
• Trop de choses circulent. Cherchez d'abord un groupe de CA Interconnected ou une arête « tous les groupes ».
• Dérive d'horloge. La validation des certificats ainsi que l'heure et la fraîcheur CoT dépendent de l'horloge ; faites tourner NTP depuis une source commune sur le hub et chaque spoke.
• Pare-feu, NAT et proxys. Le hub doit accepter 9102/tcp (et 9100/tcp seulement depuis les réseaux d'administration) ; les pare-feu à états aux délais d'inactivité courts coupent les connexions silencieuses ; les proxys à inspection TLS cassent le TLS mutuel — exemptez le chemin de fédération ou utilisez l'authentification par jeton.
• Décalage de version. Une connexion sortante réglée sur v2 mais pointée vers un port v1 — ou l'inverse — ne s'établit jamais.
• Serveurs clonés. TAK Server écrit un identifiant de serveur aléatoire dans CoreConfig.xml au premier démarrage et le tamponne comme étiquette de flux sur les messages traités, rejetant tout ce qui porte déjà sa propre étiquette, afin d'éviter les boucles de routage. Des fédérés issus d'un serveur cloné déjà initialisé partagent cet ID ; donnez à chacun le sien.

# Which certificate chain does the hub present on the v2 port?
openssl s_client -connect hub.example.org:9102 -showcerts </dev/null

# Which CAs does this TAK Server trust for federation?
keytool -list -keystore /opt/tak/certs/files/fed-truststore.jks

# Is this host's clock synchronised?
timedatectl status

Fédération directe vs Federation Hub vs un TAK Server partagé

Règle empirique : pour deux ou trois partenaires stables, fédérez directement. Pour quatre serveurs ou plus, plusieurs domaines administratifs ou une liste de partenaires qui change à chaque exercice, utilisez un hub. Pour une organisation avec une seule équipe d'administration, un TAK Server clusterisé unique avec des groupes est plus simple que n'importe quelle fédération.

Liste de contrôle de planification de la fédération

1. Inventoriez chaque fédéré : propriétaire, version de TAK Server, joignabilité et protocole (v2).
2. Choisissez la topologie avec le tableau ci-dessus ; nommez l'opérateur du hub et qui approuve sa configuration.
3. Concevez la PKI : un CA de fédération par organisation, durées de vie des certificats, dates de renouvellement et procédure de révocation ; changez les mots de passe par défaut des keystores.
4. Accordez un catalogue de groupes entre partenaires : noms exacts des groupes, ce que chaque serveur envoie (sortant) et accepte (entrant).
5. Dessinez le graphe de politique d'abord sur papier : arêtes orientées, type de filtre par arête et une décision Interconnected explicite pour chaque groupe de CA.
6. Décidez de la fédération de fichiers et de missions séparément du CoT, et laissez le bloqueur de fichiers pref activé.
7. Ouvrez le pare-feu : 9102/tcp en entrée vers le hub, 9100/tcp seulement depuis les réseaux d'administration, en sortie seule pour les spokes ; vérifiez les délais d'inactivité NAT et l'inspection TLS.
8. Synchronisez l'heure sur chaque hôte.
9. Écrivez une matrice de tests avec un cas à faire passer et un cas à bloquer par arête, et rejouez-la après chaque changement de politique.
10. Mettez en place supervision, sauvegardes et une bascule vers le hub de secours répétée.
11. Gardez un hub par domaine de sécurité ; tout ce qui traverse les domaines passe par une solution inter-domaines accréditée.