Closed Federation Messaging
You set up closed federation messaging by adding trusted partner domains to an allowlist. The chat server then blocks traffic from any domain not on that list. Teams use this setup to talk with outside partners while blocking public spam. Still, broad domain rules still let approved users send anything inside those chats. How closed federation messaging works in practice In an open setup, your chat server accepts traffic from any external domain. Anyone with a valid account on another server
Identity Federation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up closed federation messaging by adding trusted partner domains to an allowlist. The chat server then blocks traffic from any domain not on that list. Teams use this setup to talk with outside partners while blocking public spam. Still, broad domain rules still let approved users send anything inside those chats.
How closed federation messaging works in practice
In an open setup, your chat server accepts traffic from any external domain. Anyone with a valid account on another server can message your staff. Closed federation messaging flips this default rule to deny all outside domains first.
To make this work, admins build a strict list of partner domains. Both companies must add each other to their domain lists before chatting. Next, the two servers check TLS certificates to prove they own those domains. When a user sends a message, the server checks the target domain name. If the domain is on the allowlist, the server routes the message across. If the domain is missing, the server drops the request right away.
Some teams also tie these domain rules to internal directory groups. Only users in specific roles can start chats with approved outside domains. The rest of the company stays restricted to internal rooms only.
What domain allowlists solve and what they miss
A closed federation setup solves the problem of unknown outside attackers. Spammers on public servers cannot reach your team to run phishing attacks. You also stop staff from joining random external rooms with work accounts. The network boundary stays limited to partner companies you know and trust.
Yet this setup only checks the server domain and the user login. It does not check what users or bots send inside the chat room. Once a channel is open, staff often paste database rows or customer details. Engineers might run chat bots that query production systems and post the output.
Identity Federation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If a partner account gets stolen, the attacker inherits that trusted domain path. They can read old chat logs or run bot commands through the channel. Domain rules decide who enters the room, not what data crosses the wire. Teams still need a way to inspect commands and mask fields in flight. For example, masking rewrites matched emails, phone numbers, card numbers, or national IDs in results.
How to manage partner roles and chat bots
Start by auditing every external domain on your current allowlist every quarter. Remove partner domains as soon as a joint project or contract ends. Next, split your internal users into clear groups based on daily tasks. Most engineers do not need to chat with outside vendors every day.
Treat chat bots and webhooks in federated rooms with extra care. A bot in a shared room can expose internal systems to outside guests. Never let a shared room bot run with broad admin keys or roles. Set up separate bots for external rooms with strict read-only permissions. Finally, log every command triggered from a federated room for your audit team.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between open and closed federation?
Open federation lets your chat server talk to any other server on the internet. Closed federation blocks all outside servers unless you add their domains to an allowlist.
Do both companies need to set up domain rules?
Yes, both sides must add each other to their domain allowlists. If only one side updates its list, the other server will reject the traffic.
Does closed federation stop sensitive data leaks in chat?
No, domain rules only check which servers can exchange messages. Users inside an approved chat can still paste customer emails, card numbers, or keys.