Defense Dev Solutions- TAK Server federation lets users on separate TAK Servers, run by separate organizations, work on the same picture.
- Each organization keeps its own users, certificates and rules, and decides exactly which data leaves its server.
- Trust is built on certificates: organizations exchange their public certificate authorities, which are kept apart from the ones local users connect with.
- Nothing flows until both sides choose the groups they will share, so sharing is opt-in on both ends.
- Missions and data packages can federate too, and a Federation Hub can replace many point-to-point links with one central policy.
What TAK Server federation is
TAK Server federation connects two or more TAK Servers so that their users can share data, even when each server is run by a different organization. A county fire department and a state emergency agency, two military units, or a federal agency and its local partners can each keep running their own TAK Server and still see each other's positions, markers and missions.
In TAK terms, each connected server is a federate. The official TAK Server Configuration Guide describes three principles behind the design, and they explain why federation is built the way it is:
- Nothing internal is shared. An organization does not have to expose its user directory, accounts or internal structure to the organizations it federates with.
- Each side controls what it shares. Every organization decides which of its data goes out. Once shared, though, what the other side does with it is up to them.
- Users do not change anything. ATAK devices keep connecting to their own server as usual. Devices from the other organization cannot connect directly to yours.
Certificates and trust
TAK Server identifies users and servers by certificate, and federation builds on the same idea. Before two servers can connect, each organization shares its public certificate authority (CA) with the other, through a separate trusted channel agreed by the two administrators.
The important detail is where that partner CA goes. TAK Server keeps one trust store for its own users and a separate one for federates. A partner's CA is only trusted for the server-to-server federation connection. That is what allows the two servers to trust each other while still refusing a direct connection from one of the partner's devices.
When certificates are not an option
Some networks inspect and re-sign all encrypted traffic, which breaks mutual certificate authentication. For those cases, TAK Server and the Federation Hub can authenticate federation connections with tokens instead. The official documentation is clear that tokens are less secure than mutual certificate authentication, so they are a fallback for difficult networks, not a default.
Groups: deciding what is shared
Making the connection is only half the job. When two servers first federate, no data flows at all. Each administrator has to choose which of their groups may send data out to the other server and which incoming data they will accept. Only once both sides have done that does traffic start.
This is deliberate. Sharing is opt-in on both ends, so a connection between two organizations never exposes more than both of them have agreed to.
Group mapping
Groups rarely line up neatly between organizations. One agency's “Fire Ops” might need to reach another's “Incident Command”. Federated group mapping connects a group on the remote server to one or more groups on yours, so incoming data from that remote group reaches only the users it is meant for.
| Control | What it decides |
|---|---|
| Outgoing groups | Which of your data is sent to the other organization |
| Incoming groups | Which of their data you accept |
| Group mapping | Which of your users receive data from a specific remote group |
Missions, data packages and data sync
Federation carries more than live positions and markers. Missions, data packages and mission packages can also be federated, so a shared operation's overlays, files and logs stay in step on both servers and reach both organizations' users.
When the link drops
Connections between organizations are not always reliable. With mission federation disruption tolerance enabled, servers catch each other up on changes to federated missions that happened while they were disconnected. Administrators can limit how far back that catch-up goes, overall or per mission, so a long outage does not flood a constrained link when it comes back.
Keeping unwanted files out
Data packages can contain configuration files that change settings on the devices that open them. TAK Server can block chosen file types from arriving through federation, so a partner's package cannot reconfigure your users' devices.
Federation is a partnership between organizations as much as a connection between servers.
Direct federation or a Federation Hub
Two servers can federate directly with each other, and for a small number of partners that works well. As the number of organizations grows, every server has to manage a connection and trust relationship with every other, and that becomes hard to keep track of.
The Federation Hub solves this with a hub-and-spoke design. Instead of connecting to each other, each TAK Server connects once to the hub. The hub manages the connections and trust, and passes data between federates according to a policy set by its administrator. It runs separately from TAK Server.
| Direct federation | Federation Hub | |
|---|---|---|
| Best for | A few partners | Many partners, or a coalition |
| Connections | One between each pair of servers | One per server, to the hub |
| Who sets the rules | Each pair of administrators | The hub administrator, in one policy |
| Extra infrastructure | None | The hub itself, which someone has to run |
What to agree before you federate
Most of the work in a federation happens between people before any server is touched. Settle these with each partner first:
- Purpose and scope. Which operations or missions the federation supports, and which teams on each side take part.
- Groups. What each side shares and accepts, and how remote groups map to local ones.
- Certificates. How CAs are exchanged, whether you use a separate chain for federation, and what happens when a certificate expires or must be revoked.
- Network path. How the servers reach each other, who opens the connection, and whether tokens are needed.
- Topology. Direct links or a Federation Hub, and who runs the hub.
- Data handling. Which missions federate, how much history to resend after an outage, and which file types to block.
- Contacts. A named administrator on each side for changes, outages and incidents.
Detailed configuration is covered in the TAK Product Center's TAK Server Configuration Guide, published by the TAK Product Center with the TAK Server source. For help planning or running a federation between organizations, see our TAK Server services. New to TAK? Start with What is ATAK?.
Talk to the engineers who wrote this guide.