Inbound Federation
You set up inbound federation by linking an outside login system to your local app. This setup lets users log in with accounts they already own. Teams often build this trust link to avoid making new passwords for every tool. Still, teams often map outside groups to broad local roles just to move fast. Broad roles give users far more power than their daily tasks need. How inbound federation works in your stack A trust link joins two separate systems together. One side holds the user accounts a
Identity Federation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up inbound federation by linking an outside login system to your local app. This setup lets users log in with accounts they already own. Teams often build this trust link to avoid making new passwords for every tool. Still, teams often map outside groups to broad local roles just to move fast. Broad roles give users far more power than their daily tasks need.
How inbound federation works in your stack
A trust link joins two separate systems together. One side holds the user accounts and checks passwords. The other side holds the apps, servers, or databases you want to use. When a user tries to log in, the app sends them to the login system. The login system checks who the user is and builds a signed digital pass. This pass holds details like the user email and group names.
The user sends this signed pass back to the target app. The app checks the signature using a public key it saved earlier. If the key matches, the app trusts the pass and reads the group names. Next, the app matches those group names to a local role. That local role sets what the user can read or write during their session. You do not need to store passwords inside the target app at all.
How to set up the trust link and role rules
First, you register your target app inside the central login system. The login system gives you a file with its public key and issuer name. Next, you load that file into your target cloud or database system. This step tells your local system which outside passes it can trust. You must make sure both sides agree on the standard format for the pass.
After you link the two sides, you build rules to map groups to roles. A rule checks the pass for a group name like engineers or analysts. When the rule finds a match, it gives the user a specific local role. Teams should keep these local roles small and tied to single tasks. You should also set a short timer on the session so users recheck often.
Identity Federation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native role mapping solves and what it misses
Linking your login system to local roles solves a huge problem for tech teams. When someone leaves the company, you turn off one central account. That person loses their path into every linked app right away. You also stop users from reusing weak passwords across many tools. Auditors can look at one place to see which groups map to which apps.
Yet this native setup only checks who logs in at the front door. Once a session starts, the login system steps out of the way. It cannot see what queries or commands the user runs inside the app. A shared role might let fifty people read a table with card numbers. The login system cannot rewrite sensitive fields like emails or phone numbers in results. It also cannot ask a manager to approve one risky delete command in flight. To control actions inside the session, you need controls at the command level.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between inbound and outbound federation?
Inbound federation lets outside identities log into your own local system or cloud account. Outbound federation takes your local users and sends them out to log into third-party tools. Both use the same trust standards, just in opposite directions.
What happens if the central login system goes down?
Users cannot start new sessions through the trust link while the login system is offline. Active sessions usually keep working until their current session timer runs out. Teams often keep one locked-down local admin account for emergencies.
Does inbound federation hide sensitive data inside databases?
No, it only handles the login step and assigns a local role to the user. If that role can read a table, the database returns all columns in full by default. You need separate data masking rules to rewrite national IDs or card numbers in results.