Closed Federation
A closed federation lets approved partner domains log in through explicit trust rules. You set up this model by adding each trusted domain to an allowlist. Many teams start by linking their identity apps with partner systems. They map external user groups to local roles inside their own network. Problems start when those local roles grant broad rights across many tools. One broad role can expose sensitive tables or servers to outside users. How closed federation works in practice In this mode
Identity Federation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A closed federation lets approved partner domains log in through explicit trust rules. You set up this model by adding each trusted domain to an allowlist. Many teams start by linking their identity apps with partner systems. They map external user groups to local roles inside their own network. Problems start when those local roles grant broad rights across many tools. One broad role can expose sensitive tables or servers to outside users.
How closed federation works in practice
In this model, two or more separate teams agree to share login trust. Nothing works until admins on both sides exchange digital keys and metadata. Each side must list the exact partner domains it will accept. Unknown domains get blocked at the front door every single time.
When a partner user tries to log in, your app redirects them. They go back to their home login server to prove who they are. That home server checks their password and second factor. Then it builds a signed token that holds the user attributes and group names.
Your system checks the signature on that token against the saved key. If the signature matches, your system reads the group claims inside. It matches those claims to a local role on your side. The user now has an active session without needing a second password.
Why teams choose a strict allowlist over open trust
Open federation accepts login tokens from any domain that follows the standard protocol. That setup works well for public apps that anyone on the web can join. Still, enterprise systems hold private records that require tight boundary controls.
By restricting trust to known domains, you cut down the outside attack surface. You only accept claims from identity systems that meet your security standards. If a partner ends their contract, you delete their domain from your allowlist. That single change blocks all users from that partner right away.
Admins also gain clear visibility into which outside companies can reach internal tools. Security auditors always ask for a complete list of external trust links. A strict domain allowlist makes that audit check fast and simple.
Identity Federation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity federation solves and what it leaves open
This trust model solves the problem of managing passwords for outside workers. You do not need to create or reset accounts for partner staff. When someone leaves the partner firm, their home admin disables their account. They lose the ability to log in to your apps right away.
Still, federation only checks who someone is at the moment they log in. It does not watch or control what they do during their active session. Once the token maps to a local role, the login server steps back.
If that role can run queries on a production database, risks remain high. A federated user could run a broad select command and pull customer emails. They could also pull phone numbers, card numbers, or national IDs in clear text. Federation logs show that a login happened, not which commands ran next.
Teams often struggle to scope local roles down to the exact task needed. Role systems in databases and cloud consoles are often coarse and hard to maintain. To stay safe, teams need controls that inspect every query and command in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does closed federation differ from open federation?
This setup only accepts login tokens from an explicit list of partner domains. Open federation lets any external domain send identity claims without prior admin setup.
What happens when a partner updates their signing key?
Both sides must update the stored key metadata before the old key expires. If the keys do not match, login attempts from that partner will fail.
Does federation control what queries a user can run after login?
No, identity federation only handles the initial login handoff and role assignment. It cannot inspect database queries, block dangerous commands, or mask card numbers in results.