Federated Organizations
You set up federated organizations by linking trust between separate identity providers and target accounts. This link lets users from one group log in to another unit with existing accounts. Teams often build this trust across sister companies, cloud accounts, or partner groups. Still, broad shared roles often give external users too much power over production data. A single mapped role might grant full read or write power across whole databases. How federated organizations work in practice
AWS Organizations & SCPs + Federated Learning Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up federated organizations by linking trust between separate identity providers and target accounts. This link lets users from one group log in to another unit with existing accounts. Teams often build this trust across sister companies, cloud accounts, or partner groups. Still, broad shared roles often give external users too much power over production data. A single mapped role might grant full read or write power across whole databases.
How federated organizations work in practice
In a standard setup, each business unit runs its own central user directory. To share tools, admins create a trust link between the home directory and target systems. They use open standards like SAML or OIDC to pass signed login tokens across boundaries. The home system checks the user password and sends a signed claim to the target.
The target system reads that signed claim and matches the user to a local role. Admins map source group names to specific permissions in the destination account. For example, a developer group in Unit A maps to a reader role in Unit B. Users do not need a second password or a new account in the target system. When someone leaves Unit A, revoking their home account stops their login to Unit B.
This architecture works well when a parent company buys a new firm or splits teams. Each group keeps control of its own user list and local security rules. At the same time, engineers can jump into shared databases or servers when needed. Admins manage fewer passwords and avoid copying user lists across ten different cloud accounts.
What native trust solves and what it misses
Native trust links solve the problem of who can log in to a distant system. They prove user identity across company lines and remove the need for duplicate accounts. Security teams get a clear way to turn off login rights from one central place. This setup cuts down on orphaned accounts when contractors or partner staff finish a project.
Still, identity trust only checks the user at the front door during login. Once the target system grants a session, the identity provider steps out of the way. The mapped role then controls everything the user can do inside that database or server. If a partner engineer gets a broad role, they can run any query it allows.
AWS Organizations & SCPs + Federated Learning Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Identity links cannot see or filter individual commands or queries while a session runs. They cannot stop a valid user from pulling tables full of phone numbers or emails. They also cannot require a quick peer check before someone runs a risky delete command. Even if you mask card numbers or national IDs in views, raw tables keeps the session active. To control actions in flight, teams need controls that inspect every request after login.
Best practices for cross-unit role design
Start by keeping cross-unit roles as small and specific as your tools allow. Never map an external user group straight to a full admin role in your account. Instead, build narrow roles for specific tasks like reading logs or checking table status. Review your group mappings every month to make sure old project links get removed.
Separate everyday read tasks from high-risk write tasks across your linked accounts. Make users ask for short-term approval when they need to change data in another unit. Log every query and command by linking it back to the original home user identity. Clear logs help your team see what happened during an audit or a security check.
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
What is the main difference between single sign-on and federated organizations?
Single sign-on lets one team log in to many apps owned by the same company. Federated organizations link separate companies or units so users can work across different domains.
What happens when a home identity provider goes offline?
Users from that home unit cannot start new sessions in the target system during downtime. Active sessions usually stay alive until their local session token expires and needs renewal.
How do we stop external users from seeing sensitive columns?
Role mappings alone rarely stop users from reading raw columns inside an allowed table. You need data masking that rewrites matched fields like emails or card numbers in results.