Closed Federation Enterprise
A closed federation enterprise setup lets vetted partner domains log in through explicit trust rules. Teams build this model by exchanging public keys and group mappings with approved external domains. Many IT teams start by linking one identity provider to another partner directory. If you map broad partner groups to local admin roles, external users gain too much power. One bad role assignment can expose your whole database or cloud account to outside contractors. How a closed federation ent
Identity Federation + Passwordless Enterprise: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A closed federation enterprise setup lets vetted partner domains log in through explicit trust rules. Teams build this model by exchanging public keys and group mappings with approved external domains. Many IT teams start by linking one identity provider to another partner directory. If you map broad partner groups to local admin roles, external users gain too much power. One bad role assignment can expose your whole database or cloud account to outside contractors.
How a closed federation enterprise model works
In an open network, any domain can ask to talk to your systems. A closed model blocks all unknown domains at the front door. Two or more companies must sign a strict agreement before they link systems. Then, admins on both sides trade metadata files and public signing keys. The home domain checks who the user is during the initial log in step. Next, the home system creates a signed token with the user email and group names.
The target company receives this token and checks the digital signature against its saved key. If the signature matches, the target system reads the group claims inside the token. Local rules then map those outside claims to an internal role for that session. This setup means the target company never stores passwords for outside partner staff. When a contractor leaves the partner firm, their home admin disables one account. That single change stops the user from logging into any linked partner system.
Why teams map roles across partner domains
Large companies often work with external vendors, auditors, or acquired brands. Creating local accounts for every outside worker takes too much time and effort. Admins forget to delete old guest accounts when a short project ends. Those stale accounts become an easy target for attackers who steal old passwords. By using federated trust, each company keeps full control over its own user list.
Home admins enforce multi-factor checks and password rules on their own workers. The receiving company trusts that the partner ran those checks before sending the token. Still, group names rarely match across different company directories. Teams must write clear translation rules so external groups get the right local permissions. You should review these group mappings every few months to prevent permission creep. Always ask partner admins to send only the minimum claims needed for the job.
Identity Federation + Passwordless Enterprise: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What partner trust solves and what it misses
Closed federation solves the problem of who can log in from an outside firm. It stops unknown domains from sending login requests to your internal apps and servers. It also removes the need to manage passwords for people outside your company. Yet this trust model only acts at the start of a user session. Once the system maps a token to a local role, the login check is over.
The identity link cannot see what queries or commands the user runs next. A trusted partner engineer with database rights can still run a broad read query. That query might pull thousands of customer emails, phone numbers, or card numbers. Standard role mappings cannot rewrite those matched fields in results before they leave the server. They also cannot ask a manager to approve one risky command in real time. To stay safe, teams must pair login trust with controls that watch live actions.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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 is closed federation different from open federation?
Closed federation only allows logins from domains that admins set up in advance. Open federation lets systems discover and trust new domains on the fly using public lists.
What happens when a partner signing key expires?
Logins from that partner will fail right away until both teams swap the new key. Teams should track key expiration dates and rotate certificates before they stop working.
Does federated login restrict what data a partner can read?
No, federation only checks identity and assigns a starting role when the user logs in. It does not filter database rows or mask emails and card numbers during a session.